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

https://www.slideshare.net/MarkPrice7/hot-code-is-faster-code-addressing-jvm-warmup-110231712
Hot code is faster code (Page last updated August 2018, Added 2018-09-23, Author Mark Price, Publisher Aitu Software). Tips:

• The JIT Compiler can replace interpreted code at method entry points, loop back-edges (so a hot loop can be replaced as it runs), and branches
• The default JIT compilation is -XX:+TieredCompilation which starts code running in interpreted mode, and when the code is identified as "hot" applies up to 2 levels of -client optimizations and then -server optimizations
• To monitor the JIT use -XX:+UnlockDiagnosticVMOptions and -XX:+LogCompilation, the output will be in hotspot_pidPID.log, but can be hard to understand and is voluminous. Useful items include the compile_id (a count of compilations being performed), backedge_count (how many loop iterations caused the compilation), compiler (C1 - client, or C2 - server), etc. osr means on-stack-replacement. -XX:+TraceClassLoading is also useful. JitWatch is a useful tool for reading compilation logs.
• The JIT compiler optimizations include speculative ones (eg if all iterations of a branch go one way, assume it is always that and inline that branch), but since these can be invalid at some point, an "uncommon trap" is added that checks the assumption underlying the speculation is true, and if it is found to be false, the code switches back to the interpreted code, and the compilation cycle starts again.
• Strategies to improve warm-up time (getting the code compiled as quickly as possible) for applications: 1. send sufficient fake requests before accepting real requests - but if you miss a real path, an uncommon trap will be hit with live requests and performance will slow dramatically for a while until compilation optimizations are re-applied though you can use the compilation monitoring to ensure that the fake requests match up to real logged compilations; 2. use ahead-of-time compilation (some can even use the compilation information to optimize); 3. use a JVM that logs compilation information from previous runs and applies that at start-up of the next run- but these are susceptible to getting it wrong on any code changes, though you can try to use performance test runs to generate compilation logs.
• JMH -prof perfasm includes assembly level compilation for microbenchmarks, but of course microbenchmarks are not necessarily useful.
• Best practices include: small methods; branches that are mostly one outcome (megamorphic call-sites are optimized if biased); tests with compilation logging on; watch for failures to inline and adjust code to let them, this is the top compilation optimization; watch for de-optimizations and change the code or the warm-up tests so they are avoided.

https://www.youtube.com/watch?v=husm8xMJ2So
Back to the CompletableFuture: Concurrency in Action (Page last updated July 2018, Added 2018-09-23, Author Dmitry Vinnik, Publisher Devoxx). Tips:

• Immutability and Atomicity make concurrency simpler.
• Callable: no input, has output, has exceptions; Future consumes the Callable (by submitting it to an Executor). But Future blocks, can't chain nor combine them, and exception management is cumbersome. CompletableFuture doesn't block, can chain and combine, and handles exceptions well.
• Use CompletableFuture based on workflows: decide on the sequence of work and build a workflow and it runs. CompletableFuture.AllOf runs all tasks asynchronously without blocking; CompletableFuture.AnyOf gives you the first that completes. You can choose to process results synchronously or asynchronously.

https://4comprehension.com/completablefuture-timeout/
CompletableFuture Timeouts in Java (Page last updated August 2018, Added 2018-09-23, Author Grzegorz Piwowarek, Publisher 4Comprehension). Tips:

• In Java 9, the new CompletableFuture.orTimeout() method was added that times out an executing CompletableFuture if the timeout time is reached before the execution completes.
• In Java 9, the new CompletableFuture.completeOnTimeout() method was added that times out an executing CompletableFuture if the timeout time is reached before the execution completes, and returns a default value if it times out.
• If the timed out CompletableFuture task or pipeline blocks a thread (eg fails to cancel or the pipeline after timeout takes time), subsequent tasks could be delayed or even blocked - at the very least use async pipelining for the subsequent stages.

https://www.youtube.com/watch?v=fAdqbzyQgb0
Top Performance Challenges in Distributed Architectures (Page last updated July 2018, Added 2018-09-23, Author Andreas Grabner, Publisher Devoxx). Tips:

• Check to see if APIs you use have bulk versions, these will be more efficient (and cheaper if charged per call) when you want a lot of data.
• Determine dependencies and identify how to avoid cascading failures from dependency failures.
• Iterating over local data is quick; but if the data is moved remotely this suddenly becomes a huge bottleneck if the iteration causes a remote call for each iteration; use a bulk call to get all the data needed for the iteration so that there is only one remote call.
• Send deltas or relevant data subsets rather than all the data to reduce the load on the network and marshalling.
• Don't split tightly coupled components into separate distributed services.
• Identify the number of services your request needs to flow through to determine possible hop efficiency improvements. Automate this into your CI/CD pipeline (along with automated performance tests) so that it breaks if there is a sudden change in how many services the service is dependent on.
• Have a performance testing environment which is continuously running production load all the time, and deploy to that environment as part of CI/CD, checking key performance metrics for significant changes from last build (use transformed recent production data, cleansed of confidential data).

Jack Shirazi Back to newsletter 214 contents