In this version: Detection of more anomalies in 3rd party code (underutilized Netty I/O buffers in Couchbase code, very big arrays generated by Jackson codec, etc.)Improved analysis of unfinalized objects that may cause GC degradationBug fixes and UI improvements
There are a number of reasons to avoid using Java Finalization (that is, objects that override the finalize() method). From the GC performance perspective, the main problem with finalization is that when GC determines that a finalizable object F is unreachable, it doesn’t clean up F immediately, as it does with other unreachable objects. Instead, the GC places F on the finalization queue, which is served by a single thread. Only when that thread executes the finalize() method of
In this version: Detection of more anomaliesBug fixes and usability improvements
In this version: Detection of new common memory problems (anomalies): in Netty, Jetty and JDKBetter detection of unfinalized objectsBug fixes and performance improvements
In Java terminology, the “live set” (LS) for a given running app means all objects that are live (that is, not garbage) at the given moment. For most apps with steady workload, objects come and go from the live set, but its size remains pretty stable (after initial warmup). In contrast, if LS keeps growing, the app most likely has a memory leak. If LS size is too close to the maximum heap size (value