United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6739920 java 6u4~ use larger C heap if there are many threads
JDK-6739920 : java 6u4~ use larger C heap if there are many threads

Details
Type:
Bug
Submit Date:
2008-08-21
Status:
Resolved
Updated Date:
2010-12-03
Project Name:
JDK
Resolved Date:
2009-03-28
Component:
core-libs
OS:
linux_redhat_4.0
Sub-Component:
java.net
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u4
Fixed Versions:
6u14 (b04)

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

Description
On RHEL 4.6 64-bit 4G mem, two instances of jakarta-jmeter with 6000 threads worked fine on 6u3 64-bit.
But after upgrading to 6u6, java processes soon cause memory thrashing and become very slow.

By monitoring virtual and resident size of java processes, 6u4 and later use larger memory.  In a case,
6u7 uses 600MB or larger C heap.

By checking malloc related path on gdb, it turned out the most memory allocations come from 
ObjectMonitor allocation.

On 6u4, per-thread ObjectMonitor freelist was introdued (_omFreeList).  In some test, I saw more than
800 ObjectMonitors in average on 6u7.  ObjectMonitor size is 168 bytes on 64-bit JVM for Linux.

6000*800*168=806400000

6u3 can run the same app with 100m to 200m C heap, but 6u4 and later require much larger C heap.

C heap usage levels off at some point, but we cannot know how much memory is really needed to
a specific run of application.  Currently there is no clear limit for the ObjectMonitors on
omFreeList.  

To suppress the excessive C heap use, we need a switch to turn off the per-thread ObjectMonitor
free list or a good mechanism to control the memory usage (Or simply a better implementation).

                                    

Comments
EVALUATION

calling (uncontended) monitors from socket native code causes unnecessary monitor inflation.
                                     
2008-09-09



Hardware and Software, Engineered to Work Together