I should have added that CMS uses current occupancy + expected promoted > initiating occupancy threshold as a trigger to start. CMS is scheduled as a just in time completion. IOWs, one should schedule CMS to start so that it finishes *just* before heap would fill. A promotion failure indicates CMS was started too late and is followed by a full STW GC. Spaces are subject to resizing after the full GC. That and fragmentation are the two primary reasons for CMS failures.
Some where someone mentioned issues with Cassandra. There is a way to fragment heap such that it can't be compacted (Mark Sweep Compact or MSC) to create enough useful space. Apparently nosql implementations are susceptible to this condition. I've seen teams try to stuff cassandra data into C heap using NIO direct buffers. At the end of the day they have to solve *all* the same issues the GC guys have to solve. Oh right, before I forget, EHCache released by Terracotta suffers from the same issues as it uses the same techniques. Regards, Kirk On Aug 15, 2011, at 11:30 AM, Joseph Ottinger wrote: > Another issue to consider, besides Kirk's very good explanations, is that GC > requires a condition to run. If it's "all memory," the condition becomes very > ... iffy to specify. You can't just say "X% of memory is Eden" because that > X% is X% of *all* memory, so GC becomes tenuously predictable. > > You want that predictability. > > On Mon, Aug 15, 2011 at 3:58 AM, Kirk <[email protected]> wrote: > The graphs are from VisualVM and the views are of Java Heap. The graphics > very nicely show Java heap utilization and the collector resizing heap space > to adapt. I just skimmed skimmed but if the author is claiming that memory is > being returned to the OS and this is proof, he's mistaken. It does *not* show > memory being returned to the OS. > > Regards, > Kirk > > On Aug 15, 2011, at 9:42 AM, Mikael Grev wrote: > > > Maybe this clears some things up regarding returning memory to the OS. > > > > http://www.stefankrause.net/wp/?p=14 > > > > Cheers, > > Mikael > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > > > > -- > Joseph B. Ottinger > http://enigmastation.com > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
