Why didn’t my app throw an OutOfMemoryError? (The JVM is a Ponzi Scheme)

Home

News: Why didn’t my app throw an OutOfMemoryError? (The JVM is a Ponzi Scheme)

  1. Every once in a while we run into someone that has a Hotspot JVM that is running back to back garbage collections and yet the heap is still almost full after each attempt! When they discover that their problem is related to the JVM not having enough memory they often ask the question, "Why didn’t the JVM throw an OutOfMemoryError (OOME)?" After all my application is not making any forward progress and the reason is Java heap is almost completely exhausted, right?

    Kirk Pepperdine (our Chief Scientist) - goes into detail showing you step by step how the JVM can miselad you with regards to saying its got "just enough memory to keep going"....

    Read the full blog post!

     

  2. Not sure I would want OutOfMemoryErrors to be thrown. Far better for the application to adaptive control the workload it is concurrently processing and signal this intervention. This is how intelligently beings do it so why not humans. Another benefit in doing so means that when the application does experience an abnormal surge in workload, unrelated to its memory capacity settings, it can use the very same mechanism...and better still not involve a human.

    This can be achieved with adaptive control values or quality of service (QoS) at the application level.

    http://www.jinspired.com/site/canceling-uncontrolled-jitter-with-adaptively-controlled-jitter

    http://www.jinspired.com/site/adaptively-controlling-apache-cassandra-client-request-processing

    It is a losing strategy thinking naively that hardwired heap/gc settings will remain optimal outside of a test environment, across code releases and throughout the day of operation. Adaptive mechanisms, such as GC and JVM, need to look at ways of making such numbers adaptive themselves....all the way down to possibly one variables driving many higher layers of adaptation.