Using z/OS 1.4 and JVM 1.4.2.
In the IBM java faq http://www-03.ibm.com/servers/eserver/z ... vafaq.html
it is indicated that the full mx value needs to be allocated out of the LE stack as one contiguous chunk. If in my example I have -Xms=64M and -Xmx set to 128M. They way I read this suggestion is that the intial HEAP value for LE should be 128M plus space needed for the -Xoss parameter, plus some space for JIT'd code. Since I haven't specified oss, I'll ignore it for the moment and add an additional 8M for JIT'd code. So, I specify export _CEE_RUNOPTS="rptopts(on),rptstg(on),stack(48K,16K,any,keep),heap(136M,4M,any,free,0,4k),anyheap(4m,512k,any,free),belowheap(0,2k,free)
Once this is tuned, the rptopts(on) and rptstg(on) need to be removed for performance.
Does this appear to be a reasonable approach? Am I on the right track or have I misinterpreted something? What advantage is there to specifying an Xms value smaller than the Xmx value, as it would appear that the storage is allocated either way?
LE Tuning for the JVM
Your approach seems right to me. You might also look at chapter 19 of the JVM diagnostics guide, which has some good information on memory management.
ftp://www6.software.ibm.com/software/de ... iag142.pdf
A working knowledge of LE helps
Setting the min heap size equal to the max heap size would mean that your application would immediately allocate the maximum amount of virtual storage at initialization, and never run GC until it was full (at which time GC would take a long time). One approach for a long running application is to figure out what its minimum steady-state heap requirements are and then to set the minimum heap size to a little above that.
If you are running WAS or Tomcat, the following JSP allows you to see the heap sizes and request a garbage collection.
I would be very interested in anything you discover in your tuning efforts;
please post anything that you are able to share.
ftp://www6.software.ibm.com/software/de ... iag142.pdf
A working knowledge of LE helps
Setting the min heap size equal to the max heap size would mean that your application would immediately allocate the maximum amount of virtual storage at initialization, and never run GC until it was full (at which time GC would take a long time). One approach for a long running application is to figure out what its minimum steady-state heap requirements are and then to set the minimum heap size to a little above that.
If you are running WAS or Tomcat, the following JSP allows you to see the heap sizes and request a garbage collection.
I would be very interested in anything you discover in your tuning efforts;
please post anything that you are able to share.
Code: Select all
<html>
<head>
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE"/>
<META HTTP-EQUIV="EXPIRES" CONTENT="0"/>
<META HTTP-EQUIV="PRAGMAS" CONTENT="NO-CACHE"/>
<title>Java Heap Sizes</title>
</head>
<body>
<center>
<h1>Java Heap Sizes</h1>
<%
/**
* A simple JSP to display current Java heap sizes
*
* @author Kirk Wolf
*/
if (request.getParameter("doGC") != null) {
System.gc();
}
Runtime runtime = Runtime.getRuntime();
String sTotal = "" + (runtime.totalMemory() / 1024) + "K";
String sUsed = "" + ((runtime.totalMemory()
- runtime.freeMemory())/ 1024) + "K";
String sFree = "" + (runtime.freeMemory() / 1024) + "K";
%>
<form action="heap.jsp" method="post">
<table cellpadding=4 cellspacing=2 border=0>
<tr>
<th align="right">Runtime.totalMemory():</th>
<td><%= sTotal %></td>
</tr>
<tr>
<th align="right">Runtime.freeMemory():</th>
<td><%= sFree %></td>
</tr>
<tr>
<th align="right">Net used memory:</th>
<td><%= sUsed %></td>
</tr>
<tr>
<td><input type="submit" name="refresh" value="Refresh"/> </td>
<td><input type="submit" name="doGC" value="System.gc()"/> </td>
</tr>
</table>
</form>
</center>
</body>
</html>The documentation does not seem to be correct. As I read the java faq, I should set the initial value for HEAP to be large enough to hold the -Xmx java heap plus some space for the JITC code, but my results do not pan out that way. 
As I made the LE HEAP initial size larger, the jvm started reporting that the max java heap was being reduced. Maybe I'm reading it wrong. I'm still playing and will post any further results as I get them verified.
As I made the LE HEAP initial size larger, the jvm started reporting that the max java heap was being reduced. Maybe I'm reading it wrong. I'm still playing and will post any further results as I get them verified.
gc -heap and le
I've been doing some GC & LE tuning as of late.
With 1.4.2 SR2 I believe the java heap starts out at the Xms value and failure to obtain sufficient storage from LE will result in an abort at start up. Then as the JVM runs and GC occurs the heap may expand up tothe Xmx value in chunks. But these chunks may also be "returned" which is to say the jvm heap shrinks. In the GC trace look for action=3 events which will show this happening. I've not ever seen the heap go below the Xms value.
I think the goal is to find the Xms value that allows GC to operate with out expansion. Then use Xmx to provide a cushion for the case where new applications upset the profile and avoid an out of memory conditon.
With 1.4.2 SR2 I believe the java heap starts out at the Xms value and failure to obtain sufficient storage from LE will result in an abort at start up. Then as the JVM runs and GC occurs the heap may expand up tothe Xmx value in chunks. But these chunks may also be "returned" which is to say the jvm heap shrinks. In the GC trace look for action=3 events which will show this happening. I've not ever seen the heap go below the Xms value.
I think the goal is to find the Xms value that allows GC to operate with out expansion. Then use Xmx to provide a cushion for the case where new applications upset the profile and avoid an out of memory conditon.