JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 196 contents

A colleague read about the Reference objects in an article linked to in last month's newsletter, and asked me about SoftReference based caches. My reply was that they were not very useful because of the non-deterministic way they evict, and that standard practice is to go for a limited sized cache with a specific eviction policy (like LRU). But he felt that the idea of a cache that was sensitive to memory-pressure seemed like a good idea. I suspect others do to.

A note from this newsletter's sponsor

While in principle it sounds good to have a memory-pressure sensitive cache, here's a description of it using SoftReferences. "Here's a cache for you. It provides a JCache API. If memory gets low, entries will be evicted. Entries might also be evicted if they're in the cache for too long. I can't say what too long is, because it kind of depends on the JVM and the memory at any time. Also, there's a possibility that entries can be evicted at other times too. Really any time at all. Actually, the only time I can guarantee the entry will NOT be evicted is if something else in the application is using the entry, ie there is a strong reference to the value. In those cases, even when memory is low, those entries won't get evicted. Also, you have no control over eviction, just leave it to the cache to decide." Does that really sound like an attractive cache to use?

If you really want to have memory-pressure sensitive cache, encapsulate your preferred cache and add separate functionality which detects memory pressure - you can have an explicit SoftReference which you periodically renew (the current JVM implementation has the lifetime of the SoftReference as a factor) and subclass the ReferenceQueue it gets added to so that you can trigger an action on your cache when it gets added. First check memory usage (if it's just done a GC, you may have loads free now), then maybe make the cache smaller, or dump it or ... something deterministic and appropriate to your application.

Now on to our links to tools, articles, news, talks, blogs. And if you need the tips from this month's articles and talks, as ever they are extracted into this month's tips page.

News

Java performance tuning related news.

• G1 improvements to manage 10TB heaps in Java 9 [skip the infomercial & start at +10 minutes], in "The Quest for Very Large Heaps"
• Monitoring Java Application Performance Using Thermostat
• Epsilon GC: The Arbitrarily Low Overhead Garbage (Non-)Collector
• Things I Wish I Knew When I Started Building Reactive Systems

Tools

Java performance tuning related tools.

• Glowroot Open source Java APM
• Fast small footprint HTTP server in Java outperforming both netty and nginx
• JavaMelody : monitoring of JavaEE applications
• Thermostat instrumentation tool for the Hotspot JVM

A note from this newsletter's sponsor

Articles

• Speedup Your Java Apps with Hardware Counters (Sergey Kuksenko/QCon)
• Troubleshooting Memory Issues in Java Applications (Poonam Parhar/InfoQ)
• Using jemalloc to get to the bottom of a memory leak (frederico, oswald, thomaslee/Government Digital Service)

Jack Shirazi

Back to newsletter 196 contents