Introduction

The Monitor Ownership Analysis is a dynamic analysis that records whether an object’s associated monitor has been entered and, if so, how often and by which threads. The analysis therefore keeps track of synchronized blocks and methods.

Sample Profile

The format of the profile is line‐oriented; each object on the heap corresponds to a line in the produced profile.

Below is an excerpt from a real‐world profile:

java/util/zip/ZipFile␜<init>␜(Ljava/io/File;I)V␜4	java.util.Vector	2211	1	false
java/lang/reflect/Array␜newInstance␜(Ljava/lang/Class;I)Ljava/lang/Object;␜-1 [Ljava.lang.String;	0	-1	true
?	java.lang.Class	7	0	true

The first column identifies an object’s allocation site, which is described by a quadruple of class name, method name, method descriptor, and the index of the instruction (new, newarray, anewarray, multianewarray) that performed the allocation. The four components are separated by the “File Separator” control character ('\034'). An instruction index of −1 indicates that the object was allocated using reflection, with the other three components identifying the method performing the allocation (Constructor/Array.newInstance(…)). If an allocation site could not be determined by the Monitor Ownership Analysis, this is indicated by a question mark. The Class object in the above profile, e.g., was allocated very early in the VM’s startup sequence; hence, the analysis was unable to observe the object’s allocation.

The second column identifies the allocated object’s type.

The remaining columns contain the actual profile of the changes in monitor ownership: The third column reports the number of times the object’s associated monitor has been entered. The fourth column reports the maximum number of recursive entries or −1, if the object’s monitor has never been entered. The fifth column finally reports whether the object’s allocating thread was the only thread to ever enter the monitor in question.