I agree with Andrew Rowley's advice so long as it's properly understood to
be *general* advice -- "rules of thumb." There are some very interesting
exceptions. (Aren't there always? :-))

Regarding making the Java heap "too large," there are some use cases --
Java batch, notably -- where you really do want to make the heap "too
large," or at least slightly too large. If the JVM is transitory, and if
you can avoid any/all garbage collection during the transitory life of the
program, that might be a perfectly wonderful, optimal outcome. "It
depends." Another potential scenario is stress testing, perhaps during the
initial phases, when you're trying to understand the performance and
scalability characteristics of an application before allowing garbage
collection to "interfere" with your assessments. (Maybe you don't have the
best measurement tools?) Or you're simply trying to determine how much is
"too much," so you start with "too much" in your testing.

Maybe you have a defective application that's got a memory leak, and
garbage collection eventually cannot accomplish anything. The application
instance then abends. But to avoid restarting the application instance too
frequently you throw "too much" memory at the application instance(s) until
you and/or the vendor can fix the leak. (Been there.) (It depends on your
point of view what "too much" means in these cases. Theoretically such a
defective application requires an infinite amount of heap, so it can never
have "too much.")

There are situations when it can be perfectly reasonable to page out.
Examples: development and test environments, and cloned execution instances
when you don't need all the clones running but would like to have some
paged in as demand warrants. Basically anything/everything that is highly
transient, with temporary and occasional demand, but you want to avoid full
startup. It's really "thrashing" that you want to avoid. Though paging
might be necessary to produce thrashing, it's not sufficient.

All that said, I see way too many cases of operators/sysprogs/managers
perversely trying to economize on memory, some perhaps remembering the
"good old days" when "Hello World!" required only a few bytes. For better
or worse, that hasn't been true for at least a couple decades. Suck it up
and spend the memory. :-)

--------------------------------------------------------------------------------------------------------
Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
--------------------------------------------------------------------------------------------------------

E-Mail: [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to