Reputation: 666
I have a fairly computing intensive benchmark program in Java which I am testing on a Linux server. It runs just fine on my Macbook.
If I run it on the server, the following happens: As soon as the memory footprint reaches about 324 MB, the program begins to grind to a halt. Apparently some restriction bars it from using more memory, and the garbage collector has to do more and more work to stay below this restriction. At some point, a "GC overhead exceeded" exception" is thrown.
I start java with -Xmx16000m, so that cannot be the memory limit. What are other possible limits?
These are the Java versions I am using:
Macbook:
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)
Linux Server:
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
Upvotes: 3
Views: 460
Reputation: 116442
The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown.
This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.
Upvotes: 3
Reputation: 533870
If that is the available main memory on the machine. If you run out of free memory your program will grind to a halt no matter how much virtual memory you have free.
Upvotes: -1
Reputation: 666
Thanks for the tip. My problem seems to be more specific, though. There's nothing wrong with the Java program per se. I am calling Java from Mathematica's JLink. I realize now that the 324 MB restriction must come from there (somewhere).
Upvotes: 1
Reputation: 7659
Use JConsole or JVisualVM to attach to your JVM at runtime. With these tools you can monitor the memory usage of the different memory-pools inside your JVM. JVisualVM also allows you to profile your application on a CPU or Memory basis. This might give you a better understanding of why you application does not behave the way it should.
Upvotes: 2