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