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

https://jaxenter.com/predictability-can-deliver-better-performance-115953.html
How predictability can deliver better performance (Page last updated April 2015, Added 2015-09-29, Author Richard Warburton, Publisher JAX). Tips:

• More than 3 branches is bad for performance (eg in a hierarchy where the JIT compiler cannot predict which method implementation to call amongst 3 or more).
• Use smaller data types; avoid big holes in your data; make access as liner as possible. Eg set up your loops to iterate through array elements sequentially with no skipping elements; don't use multidimensional arrays, if necessary map to a single-dimensional array and ensure you iterate the right way through adjacent elements.
• Primitive collections (trove, gs-coll, fastutil, hppc) are better if possible than full object collections; arrays are better than linked list for performance (as elements are spatially close in memory); similar hashtables are better than search trees.
• Simple sequential access/writes are very efficient. For small data reads/writes on rotational disks, disk seek time dominates (300 times slower than sequential access on lots of data). Context switches between IO threads/processes can make IO seek time dominate, as can fragmentation. ZFS and ext4 do allocation on flush which decreases fragmentation. SSD random access is slower than sequential, but only by about one order of magnitude.
• In a virtualised environment, you can continually measure the instance performance and if there is too much "steal" time (eg from vmstat, because other VMs on that box are stealing resources) then kill that VM and spin up another to get away from the noisy neighbour.

http://ejf.io/dev_blog/async_java_compare/
Comparison of Asynchronous Data Loading in Java (Page last updated September 2015, Added 2015-09-29, Author John Feig, Publisher ejf.io). Tips:

• You can perform asynchronous processing using Futures: create a reference to your future; pass a Callable to a thread-pool, and make the return type of the callable match your future type; get the value out of your future (periodically calling isDone() if you don't want to block on the get()). But note that the thread in the thread pool is blocked while the callable operates, even if it's in I/O.
• You can perform asynchronous processing using callbacks: create a method or runnable; call the callback in the method/runnable submitted to the thread-pool. Note that the callback will operate in the thread running the runnable.
• You can perform asynchronous processing using Observers: create an Observable class; implement Observer; set the value in the Observable in the task submitted to the thread-pool. Note that the Observer will operate in the thread running the Observable.

http://vanillajava.blogspot.co.uk/2015/08/managing-your-application-as-file-system.html
Managing your application as a file system (Page last updated August 2015, Added 2015-09-29, Author Peter Lawrey, Publisher vanillajava). Tips:

• Mounting your data as a file system lets you access that data externally, from any language; and use familiar filesystem tools to work on the files. This can provide efficient inter-process communication and shared data structures.
• The open source Chronicle Engine creates a concurrent map accessible from multiple processes on a box with low latency, and also from other machines via an NFS mount or via TCP replication, with event notification on changes.

https://techblog.workiva.com/tech-blog/breaking-and-entering-lose-lock-while-embracing-concurrency-part-i
Breaking and entering: lose the lock while embracing concurrency, Part I (Page last updated September 2015, Added 2015-09-29, Author Tyler Treat, Publisher workiva). Tips:

• A trie is an efficient solution for pattern matching because of its good logarithmic complexity and tendency to fit in CPU cache lines.
• Lock-free concurrency means that while a particular thread of execution may be blocked, other threads dependent on the shared resource are able to continue processing other work.
• Lock-free concurrency gives increased system throughput at the expense of increased tail latencies.
• Linearizability requires that each operation appears to occur atomically at some point between its invocation and completion. Linearizability is a correctness condition for concurrent objects. Linearizability comes at a cost.
• A global lock kills throughput, but it ensures linearization.
• Locks are expensive, not just due to contention but because they completely preclude parallelism.
• Read-modify-write operations like compare-and-swap offer a lock-free approach to ensuring linearizable consistency.
• The typical compare-and-swap (CAS) pattern is to perform some speculative work then attempt to publish the changes with a CAS. If the CAS failed, then another thread performed a concurrent operation, and the transaction needs to be retried. If it succeeded, the operation was committed and is now visible, preserving linearizability.
• The compare-and-swap (CAS) loop is a pattern used in many lock-free data structures. If another thread modifies the shared memory and changes it back before the first thread resumes execution (the ABA problem), a CAS can incorrectly succeed.

http://xpadro.blogspot.co.uk/2014/08/java-concurrency-tutorial-thread-safe.html
Java Concurrency Tutorial - Thread-safe designs (Page last updated August 2014, Added 2015-09-29, Author Xavier Padró, Publisher xpadro). Tips:

• Immutable objects are thread-safe. Immutable objects have state set on construction, and the state cannot be modified.
• Making all fields 'final' is not sufficient to make an object immutable, if any of the fields are themselves references to mutable objects. In these cases you need to prevent access to the mutable objects and only provide access to the immutable data they hold (eg via copies or access methods).
• A stateless object is immutable, and therefore thread-safe.
• ThreadLocal objects provide access to a per-thread object, and so are thread-safe.
• Any object which has single-thread scope is thread-safe (ie it is created and dereferenced within a single method and not passed to another thread nor returned from the method).
• An object with all access and update synchronized on a single monitor is thread-safe as only a single thread can access or update it at a time.

http://www.3scale.net/2015/04/how-to-load-test-and-tune-performance-on-your-api-part-i/
How to load test & tune performance on your API (Part I) (Page last updated April 2015, Added 2015-09-29, Author Victor Delgado, Publisher 3scale). Tips:

• As APIs have now become more important services from companies, their performance matters more. The API performance is a feature of the API.
• The load test workload should be as similar as possible to the one that your API will be handling in real life. This requires you to know or realistically estimate that workload - and how that workload will grow, including peak and distribution across endpoints.
• Increasingly realistic load test scenarios use: simple repetition of tests; simulated loads from the most accurate data; (simulated or replayed) traffic from real requests.
• Your load test environment needs to have as similar a capacity as possible as your real system.
• Choose a load generation tool which can most closely provide the traffic and monitoring that your load testing needs (Apache JMeter is a good free open source option if it provides the features you need [the article lists several more tools]).
• Determine the maximum throughput by increasing the load until the server reaches maximum CPU (or whatever the limiting resource) utilization.

Jack Shirazi

Back to newsletter 178 contents