Hi Markus,
thank you for this detailed answer on that topic, which is quite
interesting especially in the context of our widget ids where we should be able
to reduce the average heap consumption a little bit, since those ids can be
shared between sessions.
Ciao
Frank
Von:
rap-dev-bounces@xxxxxxxxxxx [mailto:rap-dev-bounces@xxxxxxxxxxx] Im Auftrag
von Markus Kohler
Gesendet: Montag, 4. August 2008 18:32
An: rap-dev@xxxxxxxxxxx
Betreff: [rap-dev] RAP memory consumption and Strings
Hi all,
Sorry for being late to answer some of the questions that came up a few weeks
ago about memory consumption.
I was in vacation.
In my experience there's not much knowledge out there about how Strings really
work. I have been working on performance topics for some years exclusively and
questions about Strings always came up.
The basic answer is that Strings are usually not shared automatically in
Java. There are a few exceptions such as Strings literals being
shared because the VM callls String.intern() on them automatically. There are
some API calls such as "subString" that share the internal char[].
Unfortunately the rules which calls do share something and which do not are
clear and even change from JDK version to JDK version.
You can find some information about the problems with Strings on my old weblog
at the SAP Developer Network (https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/u/6389).
Thee posts https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5100
and https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/5095
might be of interest in this context.
The basic approach I usually recommend is to use a call to String.intern() to
reuse an already existing String instance.
String.intern() is not free of problems, because it was pretty slow on SUN JDK
1.4 (and HP) and it does a global lock in case something is written the VM
internal Hashtable that is used.
In practice, I so far found that it didn't cause any real performance problems.
I'm not aware of any good generic replacement for String.intern() because, one
would need to implement a low overhead WeakConcurrentSet and that is probably
very difficult, because WeakReferences have a memory overhead that might be to
high to be accetable.
You can find some examples for real world (Netbeans, Eclipse) problems with
Strings at my new weblog at
http://kohlerm.blogspot.com/.
Regards,
Markus