Browse Prior Art Database

Efficient data collection for Java Util Conccurent locks and structures

IP.com Disclosure Number: IPCOM000239095D
Publication Date: 2014-Oct-10
Document File: 6 page(s) / 85K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a technique for integrating Java Util Concurrent (JUC) data capture as a core element of the Java Virtual Machine with little overhead.

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

Page 01 of 6

Efficient data collection for Java Util Conccurent locks and structures

Java.util.concurrent (JUC) provides an alternative to traditional Java Object locks (using synchronized) as well as a number of other Application Programming Interfaces (APIs) optimized to allow fast concurrent use. As these APIs become more broadly used, processes for capturing data that can be used to investigate/resolve performance issues related to these locks/structures become increasingly important.

Earlier attempts to capture lock information relied on instrumenting the Java classes run by the Software Development Kit (SDK).

The novel contribution is a technique for integrating JUC data capture as a core element of the Java Virtual Machine (JVM) itself. This technique does not require instrumentation of the SDK classes, which is brittle and must be done as an additional step before capturing data. In addition, the technique requires very low overhead.

Each time JUC needs a thread to wait because a lock is held, a queue is empty etc., it uses park/unpark to put the thread to sleep or wake it up. Each time it asks a thread to sleep using park, the context includes a "park blocker", which provides the link between park/unpark requests. If the same park blocker is set for one or more park/unpark calls, then those calls are related to the same instance of a JUC structure.

Key information about the behavior of JUC locks/structures can be captured by looking at the park/unpark behavior. This novel contribution is a technique to capture/report on this information.

The technique enhances the JVM to maintain a list of "park blocker" records, which contain fields for the information that must be recorded for each park/unpark pair for given park blockers. The JVM is enhanced to include a hidden field within objects that are used as "park blockers". These are a known set of classes and subclasses of these classes. In addition, each time park/unpark is called, the system gets the park blocker Object set for the park/unpark call, and then receives the park blocker record for the object using the hidden field. If the park blocker record does not already exist, it is created and added to the list maintained. When the park blocker record is completed, the system captures the information needed for the park/unpark.

The park blocker record includes a weak reference to the "Park blocker" object. Upon a user request, the process is to walk the list of park blocker records and output the information captured. In addition, if the reference within the weak reference has been cleared, then the park blocker record is removed from the list, as the object has been collected and no further data need be collected for that park blocker. Lastly, the technique infers additional attributes of the behavior based on the specific park blocker

1


Page 02 of 6

type.

Figure 1: The main data structures

The first step for implementing the new technique in a preferred embodiment is to enhance the...