Java Performance Tuning
Java(TM) - see bottom of page
Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks!
Training online: Concurrency, Threading, GC, Advanced Java and more ...
Tips March 2023
JProfiler
|
Get rid of your performance problems and memory leaks!
|
JProfiler
|
Get rid of your performance problems and memory leaks!
|
|
|
Back to newsletter 268 contents
https://blog.devgenius.io/java-deadlock-prevention-and-troubleshooting-tips-all-you-got-to-know-d12b84427d1e
Java Deadlock Prevention and Troubleshooting Tips - All You Got To Know (Page last updated February 2023, Added 2023-03-27, Author Tech Is Beautiful, Publisher Dev Genius). Tips:
- Deadlock is when two or more threads are blocked and waiting for each other to release a resource. Deadlocks can be detected from: thread stack dumps; many tools like JConsole, VisualVM; and in code from LockSupport.
- Strategies to prevent deadlocks: always acquire locks in a fixed order; avoid holding locks for extended periods; reduce the scope of the lock holding code block; use ReentrantLock and similar concurrent lock classes to manage locks, eg using tryLock() to acquire locks without blocking; use timeouts when acquiring locks to prevent threads from waiting indefinitely; use non-blocking algorithms and data structures to avoid deadlocks altogether.
https://www.youtube.com/watch?v=G40VfIsnCdo
Quarkus Runtime performance - a peek into JVM internals (Page last updated October 2022, Added 2023-03-27, Author Franz Nigro, Luis Barreiro, Publisher Quarkusio). Tips:
- Klass secondary_super_cache can limit your scaling. The JVM uses this to cache the last
instanceof
check for a class, so if you do the same check repeatedly it performs the subsequent checks very quickly. But if you are comparing against multiple classes, the cache just becomes repeatedly invalidated so is just overhead. But what's worse is that the cache invalidation is shared across threads in the CPU cache on the same cache line as the array of supertypes which get searched when the cache is inavlidated, so if comparing against multiple classes in tight CPU bound loops, you limit parallelization with this false sharing.
- Using insufficient variety of data types in testing can lead to incorrect results because not all the code paths are used and so the JIT can optimize away code that would be present in the production.
- A flame graph with broken stack frames (ones that don't seem to have an associated call stack) may indicate false sharing in the CPU cache.
https://www.kodewerk.com/general/java/memory/2022/12/11/allocating-profiling-bias.html
The Bias in Allocation Profiling (Page last updated December 2022, Added 2023-03-27, Author Kirk Pepperdine, Publisher kodewerk). Tips:
- Avoid unnecessary object allocations - reducing allocation pressure can result in dramatic improvements in performance because the performance of an application with a high allocation rate is almost always dominated by cache misses.
- Allocation profiling usually impacts the speed of allocation and the optimizations applied, so can identify spurious hot spots that have been optimized in running code. JFR uses TLAB boundary events for allocation profiling, which is a very low overhead technique but biases the profile to large allocations (as these are overrepresented in reasons for reaching a TLAB boundary).
- One option to allocation profile would be to use the Epsilon GC, and dump the heap at some point. This heap dump would have all objects allocated (since no GC happened), so would provide detailed object allocation counts.
- For allocation profiling, JFR is low overhead and convenient but has a bias towards large allocations; while profilers like VisualVM have high overhead, interfere with optimizations and can't be run in production, but do record all allocations.
Jack Shirazi
Back to newsletter 268 contents
Last Updated: 2024-08-26
Copyright © 2000-2024 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/newtips268.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us