[MUD-Dev] [TECH] String Classes, Memory Management, and Fragmentation

[Kwon Ekstrom]

From: "Jay Carlson" <nop at mitre.org>
> "Kwon Ekstrom" <justice at softhome.net> writes:

>> Please note that java interprets anything between quotes as a new
>> String automatically.  thus "bleh" is equal to new
>> String("bleh"), except that in the latter you actually create 2
>> Strings.

My point is that Java automatically converts text within quotes to
an instance of String, meaning that any method of the String can be
used on a constant.

Conceptially it's an instance of String, which is my point, but
you're right they are not ==.  However, String.equals would return
true because unlike it's parent, this method compares value, not
object reference.  A minor point I know, but still valid.

> No, that's not true.  Quoting the Java language spec, section
> 3.10.5

You're correct here, I'm sorry for not making my point more clear,
but they are 2 separate objects with equal value... I'll explain
more later.

>   | A string literal always refers to the same instance (§4.3.1) of
>   | class String.

The spec defines a String literal as:

A string literal consists of zero or more characters enclosed in
double quotes. Each character may be represented by an escape
sequence.

Which in my current example would make new String("bleh") a new
instance of String created from a literal, the output is not a
String literal.

This quote is rather interesting, I don't want to do the research
necessary so I'm taking it at it's word, although I can't see the
reasoning behind it other than to save memory.  This would mean that
you would need to modify it's value each time a literal is
referenced, which increases CPU overhead, and may cause problems
with synchonization.

>   | 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.

This says it must be a String literal, and generalizes it slightly.
I interpret this to mean that each unique instance of a String
literal are stored internally in the JVM.  This point relates
directly to the original post since it's sharing references to
uncorruptable Strings.  This is an optimization feature of Java.

This has the limitation that it's only for String literals, the
String.intern method is a way of ensuring that a String exists in
this global pool.  When called it checks if the current instance is
contained in the pool, if it is, then it returns the interned
version, otherwise it adds the current string to the pool and
returns itself.

I don't see any way to remove a String from the pool after it has
been added, the fact that it's used to store Constants supports
this, so I don't recommend the use of this method unless you are
sure that you don't want the String to be garbage collected.

I have to say that the java docs for the intern method conflict with
the previous quote: A pool of strings, initially empty, is
maintained privately by the class String.

This seems to say that each value in the pool is stored as a String
object, and since it stores the String literal constants, it would
mean that each literal has it's own instance of String.

I won't comment on you're equality point yet because I couldn't find
the reference to it on that page of the spec, and don't want to
conduct a more thorough search.  If you have the link to that it'd
be handy.

>From experience, I'd like to point out that the String.equals method
compares value, so "bleh" would be equal to an instance of String
with the same value... even if they are separate instances.

My reason for posting that in my last message was to make note that
you don't need to create an instance to use String methods, I often
use "bleh".startsWith(str) or similar syntax in my source for this
reason.  It behaves in every respect as a String.

-- Kwon Ekstrom

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev