Memory Usage: Heap space vs System Monitor

Question

Hi guys
I'm trying to wrap my head around something which seems pretty complicated. We have an enterprise app making use of Jasper Reports. When a report is generated, the app's memory usage in the Linux (Ubuntu 8.10) System Monitor shoots up by around 20MB (the more data on the report, the higher that number). After the report is closed, memory usage doesn't decrease. This is resulting in performance issues, and memory usage given by the System Monitor doesn't match up with the results given by the NetBeans profiler. There is a huge difference between the values indicated by the System Monitor, and the heap space given by the profiler. I've done some fairly detailed checking using the profiler, and according to that, there are 0 instances of our report generating classes in memory after closing a generated report. I've read a bunch of articles on the net, but I'm still stumped. My best guess is that something weird is happening somewhere in the Jasper code, but I can't really think of a way to confirm that. Does anyone have any idea what could be causing this and how to prevent it? Any help will be much appreciated; thanks.
P.S. I've posted on the Jasper forums are well, but to no avail. [http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=65335]
Edit: We're using Java 6 (we've recreated the issue on a few release of Java 6), and Jasper Reports 3.0.1. (Just in case that is important)

Answer 1

One thing about your test is that using Xms110m will cause the JVM to NEVER give back any memory, because it won't ever go below 110M. I altered your test a bit:
import java.util.LinkedList;
public class MemTest {
   private static LinkedList<byte[]> mem = new LinkedList<byte[]>();
   public static void main(String[] args) {
        try {
            System.out.println("Initial:");
            print();
            useMem();
            System.out.println("Allocated:");
            print();
            clearMem();
            System.out.println("Deallocated:");
            print();
            for (;;) {
               Thread.sleep(10000);
               System.out.println("After 10 seconds: ");
               print();
        } catch (Exception ex) {
            ex.printStackTrace();
   private static void useMem() {
      for (;;) {
         try {
            mem.add(new byte[1024*1024]);
         } catch (OutOfMemoryError e) {
            //free up a few MB to make sure we don't get an OOME while trying to print, etc
            mem.removeFirst();
            mem.removeFirst();
            mem.removeFirst();
            break;
   private static void clearMem() {
      mem = null;
      System.gc();
      System.gc();
      System.gc();
   private static void print() {
      long free = Runtime.getRuntime().freeMemory();
      long total = Runtime.getRuntime().totalMemory();
      double freeFraction = (((double)free) / (total)) * 100;
      System.out.printf("\tAvailable: %d\tTotal: %d\tFree: %4.2f%%%n", free, total,
            freeFraction);
}When I ran it with
-Xms16m -Xmx1024m -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30I got these results:
Initial:
     Available: 16518016     Total: 16711680     Free: 98.84%
Allocated:
     Available: 2070952     Total: 1065484288     Free: 0.19%
Deallocated:
     Available: 582957376     Total: 583073792     Free: 99.98%
After 10 seconds:
     Available: 582953224     Total: 583073792     Free: 99.98%As you can see, the JVM did return about half of the memory back. ProcExp shows ~592MB used, and peaked ~1000MB. But right now it's still running, and still holding at 583MB.
I've read bug reports like this, but honestly have no idea what the people at Sun are talking about. I don't see the footprint being reduced. I don't know, maybe if I wait a couple of days...