JEP 291: Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector

[kirk at kodewerk.com]

Hi again,

> 
> Also the automatic tuning around pause goals seem to fail rather often. Some consolidated work to make the predictions a bit more robust would be good.

Predications are frat with problems. We’ve spent a lot of time looking at analytics and some predictive analytics. In fact, I just spent the last month barely doing anything else. IOE, there is simply no way to account for “black swan” events and these types of event happen more frequently than you might imagine. That said, this isn’t a reason not to try, it’s just saying that you should expect to be wrong fairly often.
> 
> Having said that CMS is not better in this areas (but people are used to tune it).

Here is a case of an analytic going wrong. As you likely know, Adaptive Sizing (AS) is based on allocation rates without regard to GC overhead which leads to an interesting pathology. As GC overheads increase generally due to increased memory pressure, application allocation rates will drop. AS will respond to the reduced allocation rates by reducing heap size. So you are AS taking heap away from an application that is struggling for memory… humm….

Kind regards,
Kirk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160711/2bf3338c/signature.asc>