JDK 5.0 Native Heap Issues?

[Y Srinivas Ramakrishna]

Hi Keith --

To add to Jon's response, native heap issues would typically tend to
be orthogonal to the frequency or otherwise of Java heap collections.
(That's in theory, but for instance, native heap leaks from for example
Java full heap collections can cause slow leaks in native heap memory
of course; but see more below.)

The native heap leak might also come from something else in the
JVM which may have gone away when you switched the JDK's.

It is quite unlikely, though, that a native heap memory leak is
tied explicitly to the behaviour of CMS and of the frequency of
full heap collections.

There is however another way in which Java heap collections may relate
to native heap pressure, related to what Jon was saying. In JDK 6 CMS,
as Jon stated, all scavenge-survivors are not immediately promoted into the old
generation. That means that typically a piece of dead space (i.e. occupied
by a dead object) is likely recycled sooner than with the default settings
in JDK 1.5 CMS, where objects may get prematurely promoted and then
immediately die, but languish uncollected in the old generation because of
the realtive infrequency of those collections vis-a-vis scavenges.
The fact that unreachable objects are identified sooner in JDK 6 CMS/default
settings (when they die in the young generation) means that, if there are
associated finalizers or other kinds of weak reference objects, then
those are enqueued sooner and any post-mortem clean-ups (including
potentially any associated native storage) might likely get run
sooner (thus possibly reducing the native heap footprint as well). Do
you believe you may have in your application or in associated 3rd party
libraries native memory or resources potentially tied to objects requiring
finalization or other clean-up? If so, you might want to monitor that
churn/activity.

-- ramki

----- Original Message -----
From: Keith Holdaway <Keith.Holdaway at sas.com>
Date: Monday, August 18, 2008 5:45 am
Subject: JDK 5.0 Native Heap Issues?
To: Y Srinivas Ramakrishna <Y.S.Ramakrishna at Sun.COM>, "Jones, Doug H" <doug.jones at eds.com>
Cc: "hotspot-gc-use at openjdk.java.net" <hotspot-gc-use at openjdk.java.net>


> Hi,
> 
> We have been running an endurance test suite with LoadRunner against 
> JDK 5.0 u14 with the following VM arguments:
> 
> et JAVA_OPTS=%JAVA_OPTS% -Xms1000m -Xmx1000m -XX:PermSize=87m 
> -XX:MaxPermSize=87m -Xss96k -XX:-UseTLAB -XX:+UseConcMarkSweepGC 
> -XX:+DisableExplicitGC -XX:NewSize=128m -XX:MaxNewSize=128m 
> -Dcom.sun.management.jmxremote -Dsun.rmi.dgc.client.gcInterval=3600000 
> -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.awt.headless=true -Dsas.svcs.http.max.connections=50
> 
> And we keep seeing the following error message after 15 hours:
> 
> Exception java.lang.OutOfMemoryError: requested 655360 bytes for GrET* 
> in 
> C:/BUILD_AREA/jdk1.5.0_15/hotspot\src\share\vm\utilities\growableArray.cpp. 
> Out of swap space?
> 
> I suggested that this error is the result of native heap issues - 
> fragmentation perhaps, and so reducing the -Xmx and -Xss and 
> MaxPermGen would enable more native heap. This is a 32 bit Windows 
> box, and the /3GB switch is turned on.
> 
> The tester has added the following two VM args to enable an 
> improvement in CMS usage, since it seems our application allocates at 
> such a rate that CMS is overrun and Full GCs interrupt the CMS algorithm:
> 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=40
> 
> But he also changed the JDK to 6.0 u7, and now the endurance test has 
> run for 25 hrs?
> 
> We are not sure if the success is contributed to JDK6 or to 
> -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=40
> 
> Any ideas?
> 
> Also, is the -XX:+UseCMSCompactAtFullCollection a default behaviour 
> for JDK 5.0?
> 
> thanks
> 
> keith
> _
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use