why this young gc is so slow?

[Igor Veresov]

On Monday, August 22, 2011 at 3:28 AM, Simone Bordet wrote:
> Hi,
> 
> On Mon, Aug 22, 2011 at 11:51, Igor Veresov <igor.veresov at oracle.com (mailto:igor.veresov at oracle.com)> wrote:
> > Right. But how big do they get at the time you see the pauses you'd like to optimize? If they're rather large consider making them smaller. That will come at price (most probably) of having full GCs happening sooner.
> > 
> > Also, if you're interested in low pause times you might want to try G1 or CMS.
> 
> Are you implying that G1 or CMS do faster young collections than PS ?
> 
> I was under the impression that the basic algorithm for young
> collection was more or less the same for all GC algorithms, and
> dependent on live objects and edges (like you said in a previous
> email), but I'd be interested in knowing if there are more
> differences.
> 
No, the young collections are not faster, but the old collections sort of are (STW time, from the application perspective). Which allows for larger promotion (young->old) rates.
Plus, G1 has better adaptive sizing algorithms - you can just set the pause time goal.

> Also, if steal-task dominates, would it be right to deduce that a
> bigger young generation will give more chances to young objects to
> become garbage and therefore steal-task times will reduce ?
In theory, yes. But in reality it depends on how good the lifetime of the objects fits the generation hypothesis and what the distribution is. If a substantial portion of objects has a relatively long lifetime it doesn't make much sense to spend time copying them between the survivor spaces. Basically, the cost of keeping an object in the survivor spaces should be less than collecting it as a part of the old gen to keep the scheme beneficial. So with cheaper old collections you can allow for faster promotions.

igor
> 
> Thanks !
> 
> Simon
> -- 
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless. Victoria Livschitz