But that is not the way is actually done in the Java VM by Sun for common
platforms . . . .  is it?

--
LTP

Basically, System.gc is a tool to increase perceived performance at the
expense of regular performance.  If all that mattered was average
throughput for the entire life of the application, then System.gc would
be meaningless.  However, in real life, there are times when a one-
second delay will not be noticed, and there are times when it will seem
interminably slow.  One possible idea to increase the *perceived*
performance of the application is to run System.gc from places where a
one-second delay won't be noticed.  For example, if I'm writing an IDE,
I may call System.gc after opening a new project, because I'd rather the
resources associated with the old project are found and recycled now
when the user expects to wait, in hopes that it won't occur later on
between the user pressing the key and the key being echoed to the
screen.  The latter would be fatal to perceived performance, while now
doesn't matter at all.

System.gc is also useful for testing the behavior of the garbage
collector.

That's probably not accurate, though.  A call to System.gc can't just be
ignored; after all, the API spec guarantees that by the time a call to
System.gc returns, a "best effort" has been made to reclaim all
available space.  Calls to System.gc might do nothing if, for example,
there's already another concurrent collection in progress and the system
can't run two collections at once.  It may also return immediately if
there is no deferred garbage collection work (for example in a reference
counting scenario).  However, it doesn't appear legal for it to just
return without doing work because the VM disagrees that work needs to be
done.

Existing behavior is consistent with this.  I don't know of a VM that
will ignore System.gc based on how full the heap currently is.