Jan Blok
Unregistered
|
|
3 months ago on Java 1.4.2 I had a situation where I needed to analyze highly non-normalized data with the inmem db hypersonic, to save memory I builded intern() on all strings being inserted into the database to save memory, the result was I could load less data than without intern() being used. (I now use a hashmap to make all same strings one instance, which works fine for memory usage reduction)
BTW one rare thing I noticed that the interned strings are not visible as memory being used by the java process on windows (normal heap string usage is visible as more memory being used by java process)
|
vlad_roubtsov
member
Reged: 06/21/03
Posts: 169
|
|
Quote:
3 months ago on Java 1.4.2 I had a situation where I needed to analyze highly non-normalized data with the inmem db hypersonic, to save memory I builded intern() on all strings being inserted into the database to save memory, the result was I could load less data than without intern() being used. (I now use a hashmap to make all same strings one instance, which works fine for memory usage reduction)
Being able to load less data (no part of which is released to GC) and whether or not the interned strings are garbage collectable are completely separate issues.
The article did not address the question whether interned strings occupy less memory overall then their non-interned equivalents or how much memory the JVM allocates for interned string storage. Because interned strings are kept in memory buffer that is separate from the normal heap (and thus potentially not controlled by -Xms, -Xmx parameters) it may well be that the JVM will run out of memory sooner if you try to intern N strings compared to the situation where they are kept in the normal heap. Note that in your scenario because the interned strings are kept in the inmem db they are not released to the GC.
Indeed, you could crash Sun's 1.3 JVMs if you interned many strings AND made sure they were not garbage collectable: see bug #4497186, for example (the VM crashes when its perm gen size reaches MaxPermSize). Note once again that keeping references to all interned strings is essential to seeing this behavior. Not doing so will not cause memory problems and proves once again that interned strings are garbage collectable.
Potential dangers of interning too much data and using your own hashmap for custom interning are well covered topics. See JavaWorld's JavaTip 130 for one discussion.
Quote:
BTW one rare thing I noticed that the interned strings are not visible as memory being used by the java process on windows (normal heap string usage is visible as more memory being used by java process)
Yes, interned strings are kept in a native JVM memory area and not in the normal heap. But just because they are not in the usual heap does not mean they are not visible as the JVM process memory consumption. Data cannot just disappear -- unless it has been garbage collected and memory reclaimed.
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
