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

http://java.sun.com/developer/JDCTechTips/2005/tt0216.html
Synchronizers & Garbage Collection Options (Page last updated February 2005, Added 2005-05-31, Author John Zukowski, Publisher Sun). Tips:

• Synchronization is designed to prevent simultaneous access to critical code blocks and shared variables.
• Where a synchronized block allows only one entity to access a shared resource, a semaphore allows 'N' entities to access the resource.
• A lock is a construct for controlling access to a shared resource by multiple threads only one thread at a time can acquire the lock.
• A semaphore works as a lock with a count. When the count is zero, no one new can enter the semaphore. When the count is positive a thread can enter the semaphore.
• A permit is like a ticket or token to a lock that is associated with a semaphore. A semaphore maintains a set of permits typically for a restricted pool of resources.
• To prevent starvation (a thread never getting a resource), it is good practice to always create fair semaphores. However, there are throughput advantages if you ignore fairness.
• The Semaphore.acquire() method gets a number of permits. The methods block until a permit is available, or until the waiting thread is interrupted.
• Semaphore.acquireUninterruptibly() acquires permits but the threads block uninterrupably until the permits are available.
• Semaphore.tryAcquire() methods do not block unless a timeout is specified, letting you determine if permits are or become available.
• Example of using Sempahore: if (semaphore.tryAcquire()) {try {doSomething();} finally {semaphore.release();}}
• A barrier offers a common point (called a barrier point) for a set of threads to wait for each other before continuing their execution.
• The CyclicBarrier class allows you to create a barrier in one of two ways. You can create a barrier with a number of parties (threads), or with a number of parties and a barrier action.
• A barrier action is a Runnable task that executes when all the threads have joined together, but before the threads are released to run on their own.
• A thread joins the barrier by calling its await() method. This blocks that party until all parties are present.
• If you wish to reuse a cyclic barrier, you can call the reset method of CyclicBarrier between usages.
• Latching variables specify conditions that once set never change. This provides a way to start several threads and have them wait until a signal is received from a coordinating thread.
• CountDownLatch has a given count. It indicates how many times a countDown method must be called, one for each party involved. After the full count is reached, any threads waiting because of an await method are released.
• Exchanger offers a simplified way of communicating between threads by passing a specific object between two threads.
• Exchanger relies on a single exchange method for the transfer of one-off data between threads, using the exchange method.
• To specify the throughput collector, use the -XX:+UseParallelGC option. The throughput generational collector runs as multiple threads across several CPUs.
• The concurrent low pause collector executes concurrently to the execution of the application and is specified with either the -Xincgc or -XX:+UseConcMarkSweepGC options.
• The incremental low pause collector is no longer actively developed, but is still available. To use the incremental low pause collector, specify the -XX:+UseTrainGC command line option (note that this option will not be available in J2SE 6.0).
• The adaptive size policy options include: -XX:AdaptiveSizeDecrementScaleFactor=VALUE, Sets the adaptive size scale-down factor for shrinking. The default is 4; -XX:AdaptiveSizePolicyCollectionCostMargin=VALUE, If collection costs are within margin, reduce both by full delta. The default is 50; -XX:AdaptiveSizePolicyInitializingSteps=VALUE, Specifies the number of steps to use heuristics before real data is used. The default is 20; -XX:AdaptiveSizeThroughPutPolicy=VALUE, Specifies the policy for changing generation size for throughput goals. The default is 0.
• Concurrent low pause collector options include: -XX:CMSAbortablePrecleanMinWorkPerIteration=VALUE, Sets the nominal minimum work per abortable preclean iteration. The default is 100; -XX:CMSAbortablePrecleanWaitMillis=VALUE, Specifies in milliseconds the time to sleep between iterations when not given enough work per iteration. The default is 50; -XX:CMSBootstrapOccupancy=VALUE, Specifies the percentage CMS generation occupancy at which to initiate CMS collection for bootstrapping collection stats. The default is 50; -XX:CMSMarkStackSizeMax=VALUE, Specifies the maximum size of the CMS marking stack. The default is 4 MB; -XX:CMSMaxAbortablePrecleanLoops=VALUE, When value is greater than 0, this sets the maximum number of abortable preclean iterations. The default is 0; -XX:CMSMaxAbortablePrecleanTime=VALUE, Specifies in milliseconds the maximum time in abortable preclean states. The default is to 1000 or 1 second; -XX:+CMSPrecleanRefLists1, Sets the preclean reference lists during the (initial) preclean phase. The default is true; -XX:+CMSPrecleanRefLists2, Sets the preclean reference lists during abortable preclean phase. The default is false; -XX:CMSSamplingGrain=VALUE, Specifies the minimum distance between Eden samples for CMS. The default is 16K; -XX:CMSScheduleRemarkEdenPenetration=VALUE, Specifies the Eden occupancy percentage at which to try and schedule remark pause. The default is 50%; -XX:CMSScheduleRemarkEdenSizeThreshold=VALUE, Sets the Eden size threshold for scheduling remark If the Eden used is below this value, don't try to schedule remark. The default is 2 MB; -XX:CMSScheduleRemarkSamplingRatio=VALUE, Start sampling Eden top at least before young generation occupancy reaches 1/[ratio] of the size for a planned schedule remark. The default is 5.
• The parallel garbage collector offers two new options: -XX:ParGCArrayScanChunk=VALUE; -XX:+ParallelGCRetainPLAB
• Additional new command line options include -XX:MaxGCMinorPauseMillis=VALUE; -XX:MaxGCPauseMillis=VALUE; -XX:GCTimeRatio=VALUE ( a GCTimeRatio setting of 19 would be 5% for GC and 95% for throughput); -XX:DefaultInitialRAMFraction=VALUE; -XX:DefaultMaxRAM=VALUE; -XX:DefaultMaxRAMFraction=VALUE

http://java.sun.com/developer/JDCTechTips/2004/tt1019.html
Queues and Delayed Processing (Page last updated October 2004, Added 2005-05-31, Author John Zukowski, Publisher Sun). Tips:

• Use the Queue methods rather than Collection ones, e.g. Queue.offer() will return false if the addition fails, while Collection.add() fails by throwing an exception.
• Use the Queue methods rather than Collection ones, e.g. The Collection.remove method throws an exception when it's called with an empty collection, while the Queue.poll method simply returns null in this case.
• BlockingQueue.put() can cause the calling thread to block if the queue is full
• BlockingQueue.take() can cause the calling thread to block if the queue is empty.
• Items added to a DelayQueue must implement the new Delayed interface, which has a single method: long getDelay(TimeUnit unit). DelayQueue works as a time-based scheduling queue that is backed by a priority heap data structure. In other words, when you add an element to the queue, you specify how long the queue must wait before the element can be processed.

http://www.theserverside.com/articles/article.tss?l=JavaDoctorBookInReview
Java Doctor Chapter 5: Profiling (Page last updated January 2005, Added 2005-05-31, Author Ali Syed, Jamiel Sheikh, Publisher Manning). Tips:

• Profilers can show CPU consumption, memory profile, lock contention, and garbage-collector activity.
• If you need to see whether there is a thread deadlock, you can do so by sending a thread dump signal to the JVM.
• Use profilers when you see or sense problems with scalability, reliability, or performance.
• Where there is excessive object creation and retention, which may result in high garbage-collector activity, a profiler can help identify memory-allocation sites.
• Profilers can identify thread contention by visually showing threads that are competing for locks when the application is running.
• There are two types of profilers: those that are based on an interface available from within a JVM, and those that inject bytecode into existing Java class files. Profilers based on the profiling interface of the JVM are more detail oriented and are generally more helpful when a problem is reproducible in a controlled environment. Bytecode instrumentation-based profilers are more helpful when you?re attempting to profile applications in production.
• Profilers require plenty of CPU cycles, are intrusive in nature and thus usually change the application?s behavior. Being aware of the intrusion?s impact is critical to successful troubleshooting.
• wholesale bytecode instrumentation of all the classes in an application can result in an overload of processing overheads and information output. Because of this, most bytecode instrumentation?based profilers require you to specify target class names.
• Bytecode instrumentation?based profilers can be used in production, but with limited caution.
• Never celebrate a troubleshooting victory prematurely. When you?re identifying the source of a systemic bug, more often than not the application is plagued with multiple problems that all need to be resolved before you can claim success.
• To profile the memory, initially run the application with -verbose:gc.
• If you start to notice a pattern where fewer objects are claimed by the garbage collector for each successive collection, then it is likely that a leak exists.
• The object count for an object that is a participant to a memory leak will, after each collection, have a pattern of becoming larger and larger. If you can identify the class and object-creation place for those objects that continue to increase in count despite garbage collections, then you?ve found your leak.
• A common cause of objects leaks is inserting objects in a collection and then forgetting they?re there, so they?re never removed (garbage, the JVM is unable to collect them because they?re still referenced by the Collection object).
• When profiling an application, it should be allowed to execute until it gets to a point when all/most of the initializations have completed (unless you are profiling the initialization).
• To identify the type of objects causing an object leak, mark the number of objects existing of each type, then find later those object types that have increased the number of live instances.
• Where multiple object types take part in object leaks, they may be related, i.e. one may be creating and maintaining refernces to others. You need to examine the construction locations to identify such relationships.

http://www.theserverside.com/articles/article.tss?l=JavaDoctorBookInReview
Java Doctor Chapter 9: Action and Pitfall Tips (Page last updated December 2004, Added 2005-05-31, Author Ali Syed, Jamiel Sheikh, Publisher Manning). Tips:

• Make sure your application has access to all available CPUs.
• Use (a modified) pSpy to identify connection and other JDBC resource leaks.
• Pool connections.
• A large distributed synchronization latency can cause apparent or real data corruption problems.
• A very large number of worker threads is detrimental to the application?s overall throughput. If the CPUs are already maxed out, having more active threads than a certain threshold (specific to the server) reduces the throughput of the server.
• When lock contentions exist, performance degradation won?t be linear, and a spike in load can cause the system to stall.
• Use buffered I/O.

Jack Shirazi Back to newsletter 054 contents