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.

   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

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