|
|
|
|
Back to newsletter 281 contents
In January's tips we had this item: "In a large organization, the cost of the biggest service is going to be nowhere close to the aggregate cost of the garbage collector, or your most popular library (eg logging library), because these libraries end up in every single service. If you start profiling across a fleet of services, what matters for (in)efficiency are the code they execute in common. Garbage collection costs across an entire organization is hugely significant"
This fascinating tip points out how important reducing GC pressure is, not for individual JVMs, but for the estate of JVMs. This is a very different style of GC tuning. You can target reducing allocations (which needs code changes such as reusing objects, static memory management, off-heap memory use, in-place object editing, avoiding copies) but that's only useful for common frameworks used across many JVMs. You can target footprint, which usually comes down to keeping as few live objects in memory as possible (which could mean higher allocations and churn!) and reducing heap sizes to practical minimums. Or you can target GC overhead, choosing the GC algorithm and adjusting to minimize memory and CPU overheads, but doing that tends to cause higher pause times! Quite the balancing act, requiring specialized tuning skills, applied across large numbers of JVMs. But with direct measurable cost benefits!
Now on to all the usual newsletter list of links, tips, tools, news and articles, and as usual I've extracted all the tips into this month's tips page
Java performance tuning related news
Java performance tuning related tools
Back to newsletter 281 contents
