<div dir="ltr"><br><div class="gmail_extra">Hi Peter --<br><br><div class="gmail_quote">On Fri, May 9, 2014 at 11:01 AM, Peter B. Kessler <span dir="ltr"><<a href="mailto:Peter.B.Kessler@oracle.com" target="_blank">Peter.B.Kessler@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 05/08/14 18:04, Vitaly Davidovich wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks Peter, I understand the mess that a promotion failure causes now. Â I'm interested in your opinion on Ramki's last point, which is to defer the full gc until the next scavenge (I.e. remember that you think you may have promotion failure on next scavenge, and then do a full gc right before that next scavenge).<br>

</blockquote>
<br></div>
The algorithm used for a full collection is not well-suited for a heap in which there's a lot of garbage. Â It involves (at least) two passes: an object-graph-order marking pass to identify live objects, and then an address-order pass that looks at every object and moves it if it is live (for the compacting collectiors), or puts it on a free-list if it isn't (for the non-moving collectors). Â In contrast, scavenging is a single object-graph-order pass that examines only the live objects. Â That's why it is such a win for edens where we expect the garbage ratio to be high.<br>

<br>
Time a young generation collection on a typical 10GB eden, and one on a similarly-populated 10GB old generation. Â For science!<br></blockquote><div><br></div><div>Thanks for that crucial reminder. Indeed in the case of the ParNew collector that Vitaly appears to be using (why? if you don't use CMS in the old gen?), doing a successful parallel scavenge versus a slow serial compaction that includes those passes serially over an Eden that is full of garbage is even more stark than in the case of the parallel old collector where at least portions of those passes are done multi-threaded.</div>
<div><br></div><div>-- ramki</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If we wait until the eden is full again, when we know the old generation is also full, then we can't scavenge the young generation. Â Maybe that wouldn't bother you because you are hoping there is no next collection. Â You've chosen to use the throughput collector, where the focus is on getting the collections done in the most efficient manner. Â Ramki is suggesting the low-pause collector, where the focus is on doing most of the collection work concurrent with application work. Â If there are cycles to spare (CPU and memory) that might complete a full collection without interfering with the application, so maybe Ramki is not as concerned about cost of a failed promotion and full collection. Â One size does not fit all. Â You haven't said why you made the choice you did.</blockquote>
<div><br></div></div><br></div></div>