Re: Ranting about JVM's default memory limits...

From:

Lew <com.lewscanon@lew>

Newsgroups:

comp.lang.java.programmer

Date:

Sun, 03 Aug 2008 09:28:51 -0400

Message-ID:

<Seednf3_9fQOLwjVnZ2dnUVZ_hKdnZ2d@comcast.com>

Christian wrote:

Though there is a problem I lately stumbled upon with large dafault values.

As we see reading your post, there is no "problem" here.

I have an application holding a search structure. This search structure
is updated every hour, by building it up agian completly and throwing
away the old one.

Now as the Objects are quite old by the time they are raplaced (1 hour)
they won't be garbage collected except the program runs out of memory.

That *is* the whole point of GC, is it not?

So my Program uses normally about 80 MiB of memory .. for the rebuild of
the Structure it uses another 20 MiB.
And as I am not aware of Plugins !!! that might want extra memory of
which I don't have any clue I am going with 256MiB of heap instead of
128 MiB.
The problem now for a desktop app is that because the old objects are
not collected until I am close to 256 MiB.. Which will happen as the
heap grows by about 20 MiB each rebuild. And when reaching 250MiB the
used memory will go down to 80MiB.
This is very undesierable for a desktop app. Sure the quick fix is
easy.. calling System.gc() after each rebuild solves the problem. Though

No, it doesn't.

I was still wondering how stupid the GC handeled my situation.

Sounds like it did exactly what it was supposed to and how it's documented to.
How is that "stupid"?

If your program needs 210 MiB, it will need 210 MiB. Java is not going to
give that back to the OS, even after a call to gc(). So your "savings" saves
nothing.

Don't forget that calls to gc() can be ignored, and impose a performance
penalty if it isn't.

Your technique is not effective.

--
Lew