Young generation configuration

Y.S.Ramakrishna at Sun.COM Y.S.Ramakrishna at Sun.COM
Fri Sep 11 18:13:54 UTC 2009

Just some very general remarks ...

>> jeff.lloyd at wrote:
>>> My goal is to maximize throughput and minimize pauses.  I’m willing to 
>>> sacrifice ram to increase speed.

Ah, but you may not be able to achieve a joint optimum there;
on the contrary, maximal throughput is often achieved at
maximal pause times. Lowering pause times to within budget
currently often involves giving up some throughput.
You need to define the maximum pause time you can stand and
the minimum throughput you can tolerate, and solve that
optimization problem.

>>> The problem is that some of the pauses are just too long.

Hmm, good, we are getting closer :-) How long is "too long"?

>>> Is there a way to reduce the pause time any more than I have it now?

yes, but you will likely give up on throughput.

>>> Am I heading in the right direction?  I ask because the default 
>>> settings are so different than what I have been heading towards.

Depending on your boundary conditions (constraints on your
objective metrics, and if you can define a suitable utility
or objective function) there may be multiple optimal configurations,
or none at all, which will meet your constraints.

>>> I think I have a lot of medium-lived objects instead of nice 
>>> short-lived ones.

You also have some short-lived ones (may be about 80%?), but yes you do
have quite some (~15%?) of medium-lived ones. The total volume of
such medium-lived objects is proportional to the transactional
rate that your server is subject to, and also proportional to
the longevity of those transactions (where i am using transactions
loosely to mean how long it takes for the records associated
with those transactions to flush their state).

You mention that your application is a "reporting server".
What is your estimate of the (expected/measured)
lifetime of such a "reporting transaction"? Does it
match the kinds of object lifetimes you are seeing here?

-- ramki
hotspot-gc-use mailing list
hotspot-gc-use at

More information about the hotspot-gc-dev mailing list