United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-7032129 : Native memory usage grow unexpectedly for vm/oom/*InternedString tests

Details
Type:
Bug
Submit Date:
2011-03-29
Status:
Closed
Updated Date:
2011-04-25
Project Name:
JDK
Resolved Date:
2011-04-25
Component:
hotspot
OS:
generic
Sub-Component:
runtime
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs21 (b07)

Related Reports
Backport:
Relates:

Sub Tasks

Description
Tests 
vm/oom/production/OOMProductionTrace_InternedString
vm/oom/production/OOMProductionAnonymousTrace_InternedString

fails on win 32 becasue they run out of native memory or 32process size.
However on this machine (sunfire004) these tests should occupy about 1G of memory.

The memory overhead is very much so it caue out of native memory error.

                                    

Comments
EVALUATION

The interned string changes allow interned strings to live in main heap instead of only perm so we can allocate significantly more interned strings before running out of heap.

The use of as_unicode_string in StringTable::verify creates a lot of native memory pressure during the verify since we allocate as much space here as there are char[]s interned.  Maybe the code should just get a raw pointer to the char array or there should be a new routine that computes the hash directly from the array.  A ResourceMark in the inner loop would work too.
                                     
2011-03-29
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/352622fd140a
                                     
2011-04-01
EVALUATION

7032129: Native memory usage grow unexpectedly for vm/oom/*InternedString tests
Reviewed-by: kvn, kamg, jcoomes

StringTable::verify uses as_unicode_string to verify the hash code we
keep in the table but the only resource mark is outside the loop.
This means that verification makes a copy of the entire StringTable in
a resource area.  Now that interned strings aren't in perm the
StringTable can become as large as the Java heap which means
verification can overflow the address space.  The fix is to compute
the hash directly from the char[] instead of making a copy.  I moved
the hash_string logic into java_lang_String and updated the users
appropriately.  Tested with test case that allocates interned strings
until we run out of heap.
                                     
2011-04-01



Hardware and Software, Engineered to Work Together