<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="http://binujohn.ulitzer.com"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>Latest News from Binu John</title>
 <link>http://binujohn.ulitzer.com/</link>
 <description>Latest News from Binu John</description>
 <language>en</language>
 <copyright>Copyright 2012 Ulitzer.com</copyright>
 <generator>Ulitzer.com</generator>
 <lastBuildDate>Thu, 17 May 2012 18:54:21 EDT</lastBuildDate>
 <docs>http://backend.userland.com/rss</docs>
 <ttl>360</ttl>
<item>
 <title>Book Excerpt: Java Application Profiling Tips and Tricks - Part 2</title>
 <link>http://binujohn.ulitzer.com/node/2088381</link>
 <description>In early JVM releases, it was common to delegate Java monitor operations directly to operating system monitors, or mutex primitives. As a result, a Java application experiencing lock contention would exhibit high values of system CPU utilization since operating system mutex primitives involve system calls. In modern JVMs Java monitors are mostly implemented within the JVM in user code rather than immediately delegating them to operating system locking primitives. This means Java applications can exhibit lock contention yet not consume system CPU. Rather, these applications first consume user CPU utilization when attempting to acquire a lock. Only applications that experience severe lock contention may show high system CPU utilization since modern JVMs tend to delegate to operating system locking primitives as a last resort. A Java application running in a modern JVM that experiences lock contention tends to show symptoms of not scaling to a large number of application threads, CPU cores, or a large number of concurrent users. The challenge is finding the source of the lock contention, that is, where are those Java monitors in the source code and what can be done to reduce the lock contention.&lt;p&gt;&lt;a href=&quot;http://binujohn.ulitzer.com/node/2088381&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Wed, 07 Dec 2011 12:00:00 EST</pubDate>
 <guid isPermaLink="true">http://binujohn.ulitzer.com/node/2088381</guid>
 <comments>http://binujohn.ulitzer.com/node/2088381#feedback</comments>
</item>
<item>
 <title>Book Excerpt: Java Application Profiling Tips and Tricks</title>
 <link>http://binujohn.ulitzer.com/node/2067673</link>
 <description>Most Java performance opportunities fall into one or more of the following categories:
Using a more efficient algorithm. The largest gains in the performance of an application come from the use of a more efficient algorithm. The use of a more efficient algorithm allows an application to execute with fewer CPU instructions, also known as a shorter path length. An application that executes with a shorter path length generally executes faster. Many different changes can lead to a shorter path length. At the highest level of the application, using a different data structure or modifying its implementation can lead to a shorter path length. Many applications that suffer application performance issues often use inappropriate data structures. There is no substitute for choosing the proper data structure and algorithm. As profiles are analyzed, take notice of the data structures and the algorithms used. Optimal performance can be realized when the best data structures and algorithms are utilized.&lt;p&gt;&lt;a href=&quot;http://binujohn.ulitzer.com/node/2067673&quot; target=&quot;_blank&quot;&gt;read more&lt;/a&gt;&lt;/p&gt;</description>
 <pubDate>Fri, 25 Nov 2011 09:45:00 EST</pubDate>
 <guid isPermaLink="true">http://binujohn.ulitzer.com/node/2067673</guid>
 <comments>http://binujohn.ulitzer.com/node/2067673#feedback</comments>
</item>
</channel>
</rss>

