🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.lang.java.programmer
2 messages
2 total messages Started by Mike Manning Thu, 07 Oct 1999 00:00
OutOfMemoryException when memory is available
#411
Author: Mike Manning
Date: Thu, 07 Oct 1999 00:00
71 lines
2923 bytes
While researching an OutOfMemoryException, when all appearances are that
there is memory available, I discovered that several others have had
this problem.

This small piece of code, borrowed from BugParade #4209215, reflects the
problem we are encountering.


public class Gctest7 {
  static long totalMem;
  static long freeMem;
  static int pFree;
  static double pctFree;
  static int count;
  static Object[] objArray;
  static Integer max;

  public static void main(String[] args) {
    max = Integer.valueOf(args[0]);
    try {
      test();
    }
    catch(Throwable thr) {
      System.err.println("Caught " + thr.getClass().getName());
      System.err.println(thr.getMessage());
      thr.printStackTrace();
      System.err.println("FAILED: " + pFree + "% free " +
                       " total = " + totalMem +
                       " free = " + freeMem +
                       " count = " + count);
    }
  }

  static void test() {
    objArray = new Object[max.intValue()];
    count = 0;

    for (int i = 0; i < max.intValue(); i++) {
      freeMem = Runtime.getRuntime().freeMemory();
      totalMem = Runtime.getRuntime().totalMemory();
      pctFree = (double) freeMem / (double) totalMem;
      pFree = (int) (100.0 * pctFree);
      System.err.println("DATA: " + pFree + "% free " +
                         " total = " + totalMem +
                         " free = " + freeMem +
                         " count = " + count);
      objArray[i] = new byte[1];
      count++;
    }
  }
}

This has been run with the -mx4m and -ms4m options, just like in the
example.

It will consistently throw the OutOfMemory exception showing something
like 37% available.  I have tried it over several JDKs on both classic
and hotspot VMs.

I find it hard to believe that this simple program fails and Sun does
not consider it to be a bug.

I realize that upping the mx parm will help, but in the real life
example it is already quite large, and there is memory available.

Any advice or workarounds that get the above to function properly would
be greatly appreciated.

Thanks!

Mike
Re: OutOfMemoryException when memory is available
#412
Author: Artur Biesiadowski
Date: Fri, 08 Oct 1999 00:00
53 lines
2738 bytes
Mike Manning wrote:
> 
> While researching an OutOfMemoryException, when all appearances are that
> there is memory available, I discovered that several others have had
> this problem.

[...]

I've changed test a bit to print only once per 100 entries to make it
run faster.

[...]
DATA: 0% free  total = 4128768 free = 7840 count = 110000
DATA: 0% free  total = 4128768 free = 5320 count = 110100
DATA: 0% free  total = 4128768 free = 2800 count = 110200
Caught java.lang.OutOfMemoryError
null
java.lang.OutOfMemoryError
        <<no stack trace available>>
FAILED: 0% free  total = 4128768 free = 280 count = 110300

This is under JDK1.3


Under JDK1.2 + hotspot program tries to gc desperately, almost stopping
program at
DATA: 3% free  total = 4063232 free = 131552 count = 113300
DATA: 3% free  total = 4063232 free = 131200 count = 113400
DATA: 3% free  total = 4063232 free = 130192 count = 113500
DATA: 3% free  total = 4063232 free = 128592 count = 113600

which is bad, but distant from 37% you were talking about.


Under JDK1.2 classic

DATA: 8% free  total = 4194296 free = 344016 count = 101600
DATA: 8% free  total = 4194296 free = 341968 count = 101700
DATA: 8% free  total = 4194296 free = 345424 count = 101800
Caught java.lang.OutOfMemoryError
null
java.lang.OutOfMemoryError
FAILED: 8% free  total = 4194296 free = 343848 count = 101900

Worst of all, still 8% is more acceptable than 37%. I've run all
programs for 500000 iterations, I'm not sure if it makes a difference.

Note that this program is quite syntetic - in classic vm a lot of memory
will be used in handles, not object data. Maybe they have some problems
with such number of handles. Anyway, under both hotspots, outcome is
quite good I think.

Artur
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads