OutOfMemoryError

[Dlugi]

Hi,

Is possible to set memory limit which reached throws
java.lang.OutOfMemoryError exception.


TIA

 

[Dlugi]

Is possible to set memory limit which reached throws

java.lang.OutOfMemoryError exception.

I don't express myself exactly, I would like:
for example when 80% of max memory is used JVM throws exception and then
I have 20% of memory available to run algorithm which release memory

 

[Twisted]

I don't express myself exactly, I would like:
for example when 80% of max memory is used JVM throws exception and then
I have 20% of memory available to run algorithm which release memory

You can use -Xmx256M and the like on the command line to give the JVM
more memory (e.g. 256 megs) but not to "reserve" some for an algorithm
to "release memory".

What you can do is make it easier for the gc to get rid of stuff you
don't absolutely need. Cached stuff can be held with SoftReference and
the like; objects you won't be using anymore can be nulled; when
objects are put in a collection or used as keys that won't be needed
in there anymore once they aren't being actively referenced anywhere
else, you can use WeakReference and WeakHashMap; and so forth.

The JVM will always try to collect garbage and will always toss softly-
reachable and less reachable objects before it resorts to throwing
OOME.

 

[Oliver Wong]

I don't express myself exactly, I would like:
for example when 80% of max memory is used JVM throws exception and then
I have 20% of memory available to run algorithm which release memory

AFAIK, this is not possible. What Eclipse does is at the beginning of
the program, it allocates a large chunk of memory (perhaps using a big
array), perhaps around 20MB. Then, it tries to catch the OOME, and upon
doing so, releases that chunk of memory (i.e. it releases the array), then
runs it's memory recovering algorithm, and presumably re-allocates the
array.

If you want to emulate the having the JVM throw the exception at 20%,
you could create a thread which continuously monitors memory usage and
throws it's own OOME when it detects memory dropping below a certain
point, but it seems to me that the exception would be thrown in the
"wrong" thread, and your other threads might not pause, waiting for your
memory-releasing algorithm to complete, unless you specifically code them
to check some sort of flag or other signal to know when they should pause,
and when they should proceed. In other words, it sounds like your
OOME-recovery code will be spread out all over your project, instead of
encapsulated at one point.

- Oliver

 

[Dlugi]

it is possible

http://www.javaspecialists.co.za/archive/Issue092.html

 

[Tom Hawtin]

I don't express myself exactly, I would like:
for example when 80% of max memory is used JVM throws exception and then
I have 20% of memory available to run algorithm which release memory

Other than free a useless piece of memory or use soft references
mentioned in other posts. Sun's 1.6 (and possibly other versions) has a
pair of relevant options.

-XX:GCHeapFreeLimit sets the percentage of heap that needs to be free in
order to prevent an OOME. It defaults to 2, so you should set say
-XX:GCHeapFreeLimit=21. It only does the check after a full GC, and you
release algorithm better not cause a full GC.

Also -XX:GCTimeLimit sets maximum percentage CPU usage for GC before
OOME. Defaults to 98.

(Disclaimer: I've not actually tried these options.)

Tom Hawtin

 

[Oliver Wong]

it is possible

http://www.javaspecialists.co.za/archive/Issue092.html

This website is essentially repeating my second suggestion: having a
thread monitor memory usage. The website's solution has all the same
problem as my solution:

<quote>
your other threads might not pause, waiting for your
memory-releasing algorithm to complete, unless you specifically code them
to check some sort of flag or other signal to know when they should pause,
and when they should proceed. In other words, it sounds like your
OOME-recovery code will be spread out all over your project, instead of
encapsulated at one point.
</quote>

The article does give an example issue more explicitly: If the other
threads aren't paused, then there may be thread gobbling up memory faster
than you can free it, and you'll end up getting an OOME anyway.

- Oliver

 

[Dlugi]

-XX:GCHeapFreeLimit sets the percentage of heap that needs to be free in

order to prevent an OOME. It defaults to 2, so you should set say
-XX:GCHeapFreeLimit=21. It only does the check after a full GC, and you
release algorithm better not cause a full GC.

Thank you, but ...
Unfortunately, this doesn't work :/

 

[Dlugi]

This website is essentially repeating my second suggestion: having a

thread monitor memory usage. The website's solution has all the same
problem as my solution:

<quote>
your other threads might not pause, waiting for your
memory-releasing algorithm to complete, unless you specifically code them
to check some sort of flag or other signal to know when they should pause,
and when they should proceed. In other words, it sounds like your
OOME-recovery code will be spread out all over your project, instead of
encapsulated at one point.
</quote>

The article does give an example issue more explicitly: If the other
threads aren't paused, then there may be thread gobbling up memory faster
than you can free it, and you'll end up getting an OOME anyway.

- Oliver

Yes, you're right, this link doesn't solve my problem :/
I wonder is it possible to do it in java