That will give you a pretty good idea what the free memory is at any
given instant.  But you may want to look into why you're getting the out
of memory trouble to begin with.  It's not always a simple matter to
free up memory.  Simply calling System.gc() will not guarantee that any
objects are in fact collected, for instance.  Before throwing that
error, the JVM will make several attempts to free sufficient memory for
the allocation it's attempting before giving up.

= Steve =

You can catch memory errors with

try{
   //allocate memory
}catch(OutOfMemoryError oome){
   //free memory
   //display error
}

In theory, yes.  In practise, the result may not be useful.  For
some JVMs obtaining those quantities (particularly runTime.freeMemory())
may be a far less trivial operation than it seems.  In a highly concurrent
application, any result you get may be completely irrelevent by the
time you get to act on it, as memory may be being churned while the
value is being computed.

As has been pointed out elsewhere, System.gc() is not guaranteed to
do anything useful (although it should really strive to do so :-) ).
If the JVM's GC is concurrent or incremental (I know at least one is,
because I implemented it) then calling System.gc() may merely schedule
a GC cycle to proceed ASAP, without the calling thread actually waiting
for it.  Even if the thread does wait, there is no guarantee that any
other thread will be similarly blocked.  In the case of a genuine OOM,
the JVM will probably try several GC cycles, amongst other things,
before finally giving up.

Stephen Thomas