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 247 contents

https://fosdem.org/2021/schedule/event/jfr/
Real World JFR: Experiences Using JFR Outside the Ivory Tower(Page last updated February 2021, Added 2021-06-29, Author Marcus Hirt, Publisher Fosdem). Tips:

• JFR events include monitor waiting times along with stack traces.
• JFR events can be captured continuously - roughly one chunk per minute per JVM is good detail, and the CPU overhead is less than 2% with LZ4 compression.
• A good exception profiling strategy is to get the count of exceptions per type, sample the stack of the first exception of a particular type, then occasionally sample stacks to keep the load low.
• JFR allocation profiling raises events when a new TLAB is allocated and when an allocation outside the TLAB happens. The JFR allocation profiler prior to JDK 16 is inefficient.
• JFR CPU profiling is not safepoint biased, but doesn't sample native threads.
• JFR has thread halt events, but these happen too often to collect, so you should only collect the outlier events (over some threshold) - though this means you may miss some interesting edge cases. JDK 16 supports rate limiting as another option.
• The JFR OldObjectSample event is very useful for solving memory leaks, includes allocation stack, time, type, and the reference chain so you can do full memory leak analysis. But it has a higher overhead and would lead to a leak (ironically) if used continuously - this should be fixed by JDK 18.

https://www.youtube.com/watch?v=TDpbt4thECc
A Simple Approach to the Advanced JVM Profiling(Page last updated March 2021, Added 2021-06-29, Author Andrei Pangin, Publisher JetBrains). Tips:

• Most sampling execution profilers have a safepoint bias that makes their results not fully accurate. Instrumentation profilers are accurate but have a large overhead which makes them only useful in specialist profiling where you can implement to limit their overhead.
• Execution profilers often can't tell if an IO call is idle or active.
• Not many profilers use AsyncGetCallTrace which doesn't wait for a safepoint to get stack traces: Oracle Developer Studio, honest-profiler, async-profiler, JProfiler.
• async-profiler can profile execution on both Java and native frames for CPU and wall-clock times, lock contention, cpu-cache-misses, page-faults, context-switches, allocations, and more.
• System.nanotime can be 2 orders of magnitude slower depending on which timer source the OS uses.
• Datagram writes have a lock which means only one thread can write at a time - the One-Nio library has a different implementation with a workaround for this.

https://www.infoq.com/presentations/java-start-fast-graal-substrate/
Starting Fast: Investigating Java's Static Compilation Landscape(Page last updated April 2021, Added 2021-06-29, Author Dan Heidinga, Publisher QCon). Tips:

• All the current work in making Java start faster: moving compilation to build time, caching loaded classes and compilations, moving initializations to later, ahead-of-time compilation, checkpoint and restore.
• checkpoint and restore involves starting the full JVM and application, and checkpointing to hold the full runtime state as an image, with the ability to start that image from when it was checkpointed - so effectively incredibly fast starting. Java projects working on checkpoint and restore for JVMs include https://github.com/CRaC/docs#crac and https://github.com/eclipse-openj9/openj9/projects/17.

Jack Shirazi Back to newsletter 247 contents