> On Jun 5, 2017, at 3:58 PM, Alexandr Nikitin <[email protected]> > wrote: > > Gil, Kirk, Thank you for the great and thorough explanation! It is an awesome > read! Almost everything fell into place. > > Indeed, Gil is right about the application pattern change. It's a high-load > API. There's a background thread that changes an internal state. The state is > ~3.5G and requires some similar amount of memory to build itself. It happens > in one background thread with lower priority. The change doesn't happen > often, once per hour or so. > > The G1 is new for me and I couldn't intuitively understand why it reacts to > the allocation pattern change like that.
All collectors in the JVM will react in a similar way. I’ve just spent 2 hours with a client explaining to them that in their case GC wasn’t at fault. It was simply shouting very loudly that something bad was happening in the application that needed to be investigated. > There's the main allocation/ collection pattern that lasts for hours. And it > needs just one background low priority thread (which allocates less memory > than worker threads) to change it :) That region number change leads to more > copying and promotions and longer pauses as a consequence (it changes max age > threshold to 1 and happens more often) > > And the actual bottom line is very simple: You need a concurrent newgen to > handle this workload, with these phase changes, without any of those > "hiccups". We can discuss that in other posts if you want ;-). > > Do you mean Azul Zing by that? Of course he does :-) And he’s not wrong. — Kirk PS, Gil, I’ll collect my commission on this lead once you close it. ;-) -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
