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 April 2009
Get rid of your performance problems and memory leaks!
Get rid of your performance problems and memory leaks!
Back to newsletter 101 contents
Forking and Joining Java to Maximize Multicore Power (Page last updated February 2009, Added 2009-04-28, Author Ted Neward, Publisher devX). Tips:
- parallelising work is a balancing between avoiding too large pieces of work which leaves threads idle, and too small pieces of work which means threading costs become large compared to the work done.
- The fork/join framework has an essential piece that decides when a problem is too small, and decouples tasks from threads.
- The fork/join framework supports a ParallelArray class that accepts a list and a fork/join pool, which can sort, filter and operate on the data in parallel.
- The original contents of a ParallelArray are never modified by the sort(), withFilter and apply() methods.
5 frameworks every software architect should consider (Page last updated January 2009, Added 2009-04-28, Author Lior Messinger, Publisher ArchITect). Tips:
- A good ORM layer would have 3 minimal features: automatic creation of objects; support record CRUD; know to deal with relations between tables.
- An event-based framework allows for simple extension of a system without wholesale rewriting - and simpler replacement of parts of the system for performance tuning.
- The biggest performance boosters ever created are from caching, so you should have a cache framework with a cache manager which centralizes few important actions: adding to the cache; retrieving; invalidation; and a single point of overall cache deletion.
- The Error and trace Framework should: distinguish between tracing (for dev) and error (always on) reporting; support real-time tracing;
Discovering Objects with Non-trivial Finalizers (Page last updated February 2009, Added 2009-04-28, Author Dr. Heinz M. Kabutz, Publisher The Java Specialists' Newsletter). Tips:
- Implementing the finalize() method is usually a bad idea.
- When a finalize() method is trivial (it has an empty body), it is ignored by the Finalizer mechanism.
- A non-trivial finalize() method will enormously slow down reclamation of the objects of that class.
- The real cost of the finalize() method is that there are handles to all those objects, causing them to survive too many collections, thus making them get promoted prematurely to the old generation.
- If Finalization can not keep up with the object creation rate, you can even get an OutOfErrorMemory.
- Each instance created with a non-trivial finalize() method on a 64-bit machine uses 64 additional bytes for the finalization, so each such object uses 80 bytes at least!
- [Article provides a mechanism for inspecting which classes have non-trivial finalizable objects, and allows watching the finalizer queue.]
The Right Time for Real Time Java (Page last updated March 2009, Added 2009-04-28, Author Paul Hohensee, Publisher ). Tips:
- To avoid GC pauses, one strategy is to set enough memory at the beginning of the day to avoid encountering GC until close.
- In many cases where GC pauses matter, what you really want is to prioritize your important tasks and ensure that they?ll never get interrupted or delayed by lower priority tasks - e.g. by using a real-time JVM.
- With the Sun real-time JVM you can produce a predictable application by changing a few declarations in an existing program; assigning real-time priorities and scheduling parameters to time-critical threads; and providing minimal configuration information for the RTGC.
- A program is predictable if its jitter (the variation in its total response time) is bounded.
- In a soft real-time application missing one or a few deadlines isn?t critical, but in a hard real-time application no deadline can be missed.
- The priorities of normal threads are in practice advisory, since non-real-time threads can be preempted by the operating system at any time.
- Threads with real-time priorities run until blocked, which means that if used carelessly they can potentially hang the system.
- Common sources of jitter include class loading and static initialization, dynamic compilation, and the execution of compiled code and garbage collection.
- You can configure a conventional JVM to achieve soft real-time predictability down to about 20 milliseconds or so on multi-processor systems. To get down below a millisecond requires a real-time JVM.
- A virtual machine normally loads a class when a program first tries to create an instance of that class, or when a program tries to use a static method or variable of that class. When a class is loaded, its static variables are initialized. You can avoid this problem by referencing and using all classes utilized by critical threads before they start executing time-critical code.
- Java RTS supports two compilation modes: Just-In-Time Compilation (JIT) and Initialization Time Compilation (ITC - allows you to control when specified classes will be compiled, specified classes are pre-loaded and marked for ITC compilation).
- The Real-Time Garbage Collector (RTGC) can be configured to execute in a very deterministic manner, though it exhibits lower throughput than non-real-time collectors, particularly on uniprocessors. It also requires a larger heap because it recovers memory in relatively small chunks, which results in a larger object representation than that used in non-real-time collectors.
- The RTGC has an auto-tuning mechanism that tries to find the best balance between determinism and throughput. Expert users can configure the auto-tuning system in order to improve that balance.
Measuring Parallel Performance: Optimizing a Concurrent Queue (Page last updated December 2008, Added 2009-04-28, Author Herb Sutter, Publisher Dr. Dobb's Journal). Tips:
- Moving work out of the critical section of code which is contended, improves concurrency scalability
- Reduce sharing of the same data by isolating threads to use different parts of a data structure.
- To understand code scalability: Identify the key different kinds of work & stress test different amounts of each type; vary the data types and sizes; measure total throughput; measure throughput for different numbers of threads; look for contention; watch for oversubscription (more parallelism than the cores could theoretically handle).
Java concurrency with thread gates (Page last updated March 2009, Added 2009-04-28, Author Obi Ezechukwu, Publisher JavaWorld). Tips:
- Thread gates are used where one set of threads has to be prevented from proceeding beyond a determined point, whilst another set of threads is active.
- [Article details a thread gate class implementation that employs a fair scheme so that elements are handed out efficiently more or less in the order in which the threads arrive, without delaying additions to the element collection.]
Java Hashed Collections (Page last updated January 2009, Added 2009-04-28, Author Mark Grand, Publisher Gamelan). Tips:
- The HashSet class is used to manage a set of objects that have unique values (using the equals method).
- The HashMap class organizes pairs of objects so that no two pairs have equal keys - for each key in a HashMap, there is exactly one corresponding value.
- The amount of time a HashMap takes to find an object pair by its key object is about the same for all object pairs in a HashMap and independent of the number of object pairs in the HashMap.
- One reason to use a HashMap or HashSet is because search, add, and remove operations are fast. A possible reason not to use a HashMap or HashSet is that they do not keep objects in any particular order.
- Finding an object pair in a HashMap by its value is not fast - the containsValue method looks at each of the object pairs in the HashMap until it finds one with the given value - containsValue must check every object pair in the HashMap before it can conclude that there is no object pair with the specified value.
- When different objects hash to the same array index, it is called a hash collision. HashMap resolves this by chaining the objects in a linked list at that index. This means that looking for an object in a chained hash table entry requires looking at all of the objects in the linked list - and the longer a linked list gets, the longer it takes to search. The more hash collisions occur, the more time it takes to search for objects.
- There are two things that will keep the number of hash collisions low: make it unlikely that two different objects in a hash table will have the same hash code; and make the array in the hash table large enough that collisions become unlikely.
- The constructor HashMap(initialCapacity) argument is the length of the hash table array that the HashMap will use when it is constructed.
- Ideally, a class's hashCode method should return a different value for each distinct value that the class's instances can have - this minimizes collisions.
- Loading factor is a ratio of the number of objects in the HashMap to the length of the hash table array. If the number of objects in a HashMap exceeds this ratio, the HashMap object makes the hash table larger.
- Excessively large values for initial capacity or small values for loading factor can make HashMap iterators slow.
- ConcurrenthashMap is a thread safe alternative to the non-thread safe HashMap.
- IdentityHashMap compares objects by identity (==) rather than equals.
- LinkedHashMap combines a HashMap with a doubly linked list so that the keys in the HashMap can be kept in a particular order.
- WeakHashMap has keys removed by the garbage collector when there are no other references to those key objects
- WeakHashSet has objects removed by the garbage collector when there are no other references to those objects
Back to newsletter 101 contents
Last Updated: 2021-03-29
Copyright © 2000-2021 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.
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us