Browse Prior Art Database

Dynamic Detection of Oversynchronization of Java Objects Disclosure Number: IPCOM000024637D
Original Publication Date: 2004-Apr-02
Included in the Prior Art Database: 2004-Apr-02
Document File: 5 page(s) / 42K

Publishing Venue



In this brief article, I shall describe a method for detecting oversynchronized Java instance objects during an execution of a given Java application. Oversynchronization is an unnecessary cost in terms of execution time that may result in performance degradation of the application in question. To be able to detect that oversynchronization exists and to further identify the objects that are oversynchronized are significant steps to mitigate the problem. By having that information, one can go back and review the source code of the classes for those objects and determine how it can be rewritten to eliminate oversynchronization. There are known methods to detect oversynchronization through static analysis of Java source code. This article will describe a different approach using live detection at runtime through actual monitoring.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

Page 1 of 5

Dynamic Detection of Oversynchronization of Java Objects

Title: Dynamic Detection of Oversynchronization in Java Programs


In very simplistic terms, performance analysis is mainly the art and science of characterizing the performance of a piece of software and investigating the underlying cause of any performance problems found. It involves the process of identifying the bottlenecks present in a given program. In multi-threaded programs, bottlenecks are a much more prevalent since they connote "contention" of a scarce or slow-responding resource by concurrently running threads. Bottlenecks manifest in many various form but they all share the same fundamental characteristics

a) Convergence - concurrent threads will eventually converge or meet at the same point where the bottleneck occurs at the same time.

b) Limited Capacity - the number of threads that converge exceeds the capacity of the resource in question.

c) Waiting - consequential to (b), some threads are blocked until there is available capacity in the resource. The wait duration is most of the time undetermined although in some cases, an upper bound can be set programmatically to prevent starvation.

A majority of the source of bottlenecks can be traced back to application design. Sometimes, it can be caused by the infrastructure on which the application depends such as network latency or database problems. We call these macro-level bottlenecks. Bottlenecks can occur also as a result of the programming language semantics. These semantics are of course needed to achieve the desired effect as defined by the language but when used indiscriminately by application writers, they may affect the overall performance in a significant way. Since these types are rather more primitive (in the sense of programming language primitives), we call them micro-level bottlenecks.

The Oversynchronization Problem

The Java programming language is a concurrent language, meaning it supports multiple threads running in one application. The most common issue with concurrent languages is synchronization. A perfectly concurrent program is when all the running threads in that program are completely independent and that they do not share anything. This is a very uncommon case because threads interact with each other and/or share a common resource in most cases, e.g. a connection pool, a piece of code, an object, etc. Thus, concurrent languages normally provide a mechanism to synchronize access to shared resources as part of the language semantics itself. For example, Java provides the "synchronized" qualifier to enforce exclusive access to a piece of code.

1 class fooClass { 2

3 byte[] barrier = new byte[1]; 4

5 synchronized public void foo1 ( int c ) 6 {

7 ... <body of method> ... 8 }


10 public void foo2 ( int c) 11 {


Page 2 of 5


13 .... < method code > ,,,
14 synchronized (barrier) { 15 16 ...< block code > ... 17 }
18 19 .... < more method code > ,,,
20 }


22 }

Figure 1: A Java Class...