early OutOfMemory exception

[Alex Mizrahi]

when lots of small objects are allocated, JVM can starve "thrashing" before
OutOfMemory exception is generated -- it does major GC very frequently, but
very little memory is reclaimed. i'd prefer it to throw OutOfMemory
exception as soon as possible when memory is near it's limit -- in this case
i'll see that there is not enough memory and adjust task parameters
accordingly.

can GC be tuned this way?

only thing i've found so far is about Throughput Collector
(-XX:+UseParallelGC):

5.2.3 Out-of-Memory Exceptions

The throughput collector will throw an out-of-memory exception if too much
time is being spent doing garbage collection. For example, if the JVM is
spending more than 98% of the total time doing garbage collection and is
recovering less than 2% of the heap, it will throw an out-of-memory
expection. The implementation of this feature has changed in 1.5. The policy
is the same but there may be slight differences in behavior due to the new
implementation.

but i don't really need parallel GC, and i'm not sure it would work
correctly in my case. other options?

 

[Tony Winslow]

when lots of small objects are allocated, JVM can starve "thrashing" before
OutOfMemory exception is generated -- it does major GC very frequently, but
very little memory is reclaimed. i'd prefer it to throw OutOfMemory
exception as soon as possible when memory is near it's limit -- in this case
i'll see that there is not enough memory and adjust task parameters
accordingly.

can GC be tuned this way?

only thing i've found so far is about Throughput Collector
(-XX:+UseParallelGC):

5.2.3 Out-of-Memory Exceptions

The throughput collector will throw an out-of-memory exception if too much
time is being spent doing garbage collection. For example, if the JVM is
spending more than 98% of the total time doing garbage collection and is
recovering less than 2% of the heap, it will throw an out-of-memory
expection. The implementation of this feature has changed in 1.5. The policy
is the same but there may be slight differences in behavior due to the new
implementation.

but i don't really need parallel GC, and i'm not sure it would work
correctly in my case. other options?

You can implement your own object creation and destruction manager.
Whenever you are about to create an object, check the current memory status.

 

[Kevin McMurtrie]

when lots of small objects are allocated, JVM can starve "thrashing" before
OutOfMemory exception is generated -- it does major GC very frequently, but
very little memory is reclaimed. i'd prefer it to throw OutOfMemory
exception as soon as possible when memory is near it's limit -- in this case
i'll see that there is not enough memory and adjust task parameters
accordingly.

can GC be tuned this way?

only thing i've found so far is about Throughput Collector
(-XX:+UseParallelGC):

5.2.3 Out-of-Memory Exceptions

The throughput collector will throw an out-of-memory exception if too much
time is being spent doing garbage collection. For example, if the JVM is
spending more than 98% of the total time doing garbage collection and is
recovering less than 2% of the heap, it will throw an out-of-memory
expection. The implementation of this feature has changed in 1.5. The policy
is the same but there may be slight differences in behavior due to the new
implementation.

but i don't really need parallel GC, and i'm not sure it would work
correctly in my case. other options?

These limit the GC effort:

-XX:GCTimeLimit=
-XX:GCTimeRatio=
http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html


Also, Sun's handling of SoftReferences sucks ass. If your app is
constantly performing full GCs without actually running out of memory,
try tuning this:

-XX:SoftRefLRUPolicyMSPerMB=
http://java.sun.com/docs/hotspot/HotSpotFAQ.html