Long remark due to young generation occupancy

[Gustav Åkesson]

Hi,

(Sorry for spam, Jon - didn't reply below to all in gc-use)

There could be thousands of thread stacks to scan. Some applications make
heavy
use of soft References. Class unloading happens at remark. The young gen is
not
necessarily empty after a young collection. Some applications make good use
of the
survivor spaces.

Perhaps our application is less dependant on this, since we're only having
a couple of hundred threads, no use of soft references and hardly every
unload any classes. Also our aim is to have every request's allocation die
in eden (or first collection from survivor). Likely my ideas presented here
is well-suited for our application due to these reasons - our biggest
remark bottleneck is the size of young generation.

Some applications can be easily scaled up to the point where the
allocation rate (and promotion rate because of their object lifetimes)
exceeds the rate at which CMS can collect. Such applications sometimes
are run with very little excess space in the heap and any delay in
any part of the CMS collection can mean CMS loses the race and
falls back to a full collection. That's all I'm saying. If you're not
in that situation, don't worry about it.

 But if the application is scaled up to an extreme allocation rate (and
promotion rate) then we will also hit YGCs more often, which means that the
abortable preclean will exit and schedule remark and then sweep. Then it
doesn't matter if abortable preclean if 5000 or 30000 in case YGC hits e.g.
every 3s - right? On the other hand, in case the allocation rate (and thus,
also promotion rate) is low then the abortable preclean runs and the
garbage is not bothering anyone sitting on the heap waiting for a YGC.
 An update for this experiment - during the night I ran 57 CMS collections
and 52 of them were below 10ms. The other 5 were pretty long - 100ms to
200ms and yet again the pauses can be correlated towards the occupancy of
young. In the long pauses, after exiting the abortable preclean 100ms
lapsed before starting the remarking, making eden have roughly 120mb of
occupancy.
 Folks, I'd very much appreciate if we could keep this discussion alive and
please give any input possible regarding these flags. Any input or
experience is appreciated
Thanks for your insights, Jon.
 Best Regards,
Gustav Åkesson


On Thu, Jan 16, 2014 at 9:26 AM, Gustav Åkesson
<gustav.r.akesson at gmail.com>wrote:

> Hi,
>
>
> There could be thousands of thread stacks to scan. Some applications make
> heavy
> use of soft References. Class unloading happens at remark. The young gen
> is not
> necessarily empty after a young collection. Some applications make good
> use of the
> survivor spaces.
>
>
> Perhaps our application is less dependant on this, since we're only having
> a couple of hundred threads, no use of soft references and hardly every
> unload any classes. Also our aim is to have every request's allocation die
> in eden (or first collection from survivor). Likely my ideas presented here
> is well-suited for our application due to these reasons - our biggest
> remark bottleneck is the size of young generation.
>
>
>
> Some applications can be easily scaled up to the point where the
> allocation rate (and promotion rate because of their object lifetimes)
>  exceeds the rate at which CMS can collect. Such applications sometimes
> are run with very little excess space in the heap and any delay in
> any part of the CMS collection can mean CMS loses the race and
>  falls back to a full collection. That's all I'm saying. If you're not
> in that situation, don't worry about it.
>
>
>
> But if the application is scaled up to an extreme allocation rate (and
> promotion rate) then we will also hit YGCs more often, which means that the
> abortable preclean will exit and schedule remark and then sweep. Then it
> doesn't matter if abortable preclean if 5000 or 30000 in case YGC hits e.g.
> every 3s - right? On the other hand, in case the allocation rate (and thus,
> also promotion rate) is low then the abortable preclean runs and
> the garbage is not bothering anyone sitting on the heap waiting for a YGC.
>
>
> An update for this experiment - during the night I ran 57 CMS collections
> and 52 of them were below 10ms. The other 5 were pretty long - 100ms to
> 200ms and yet again the pauses can be correlated towards the occupancy of
> young. In the long pauses, after exiting the abortable preclean 100ms
> lapsed before starting the remarking, making eden have roughly 120mb of
> occupancy.
>
>
> Folks, I'd very much appreciate if we could keep this discussion alive and
> please give any input possible regarding these flags. Any input or
> experience is appreciated
>
> Thanks for your insights, Jon.
>
>
> Best Regards,
>
> Gustav Åkesson
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20140117/bf18a946/attachment.html