Architecture Visualization The Craft Of Jvm Instrumentation And Monitoring Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The world has evolved into a maze of complex programs and software. Software industry has boomed and has taken over most part of the industry, including mechanical, electrical as well as Information Technology. The major goal of developing software is to "un-complicate" the methods and terminology used in the earlier times. Today automation is in demand, and programmers drink, eat and sleep on code.

Visual "coming from the eye or sight" [13] means relating to vision or sight. Visualization is prevalent in many fields around the world, and is heartily accepted as one of the most important means of understanding as well. There is no doubt that the internal structure of a tool: software or not, can be difficult to understand. Nevertheless, understanding the working as well as the structure of these tools is of utmost importance in order to understand and create better and updated tools. Our mind can grasp things better visually as opposed to text and other means of information sharing. This concept is used in order to understand the complex structures surrounding us. These strategies of visualization can be applied to the field of software engineering in order to understand the flow and the make of the very complicated programs available today.

Visualization can be used in two ways: It can either be used when creating a picture of real world entities or it can also be used to denote interactions between these entities along with their graphical representations.

Software Architecture

Software architecture, which is largely underestimated, plays a key role between user requirement and implementation. Most general purpose programming languages do not have any specific representation of software architecture. A successful architecture keeps on growing, and so does its internal architecture. Sometimes, during the growth phase this flow goes adrift.

Our tool focuses on understanding the underlying documentation as well as the internal architecture of any software created using java. Any software has a number of stakeholders: architects, designers, sales, developers, maintenance team etc. Each of these stakeholders has a different view of the system. Thus, a software architecture visualization tool keeps all of these different stakeholders in mind and helps them play a role during a system's lifetime.

One of the basic reasons to study software architecture is that we can find out the deviation between the theoretical architecture to the outcome which is the practical architecture. Understanding the architecture is of real importance so that each of the stakeholders can play an equally important role during the life cycle of the product.[1][3]

Software architecture visualization

The force behind visualizing software comes from the need to reduce cost of software development and evaluation. Understanding the product at various stages of the software development life cycle is really important but is, by no means, an easy task. Visualization techniques can help all of the concerned stakeholders to actually probe into the software and understand it during different levels of abstraction. Another advantage is that it provides visual information which is easier to understand as compared to other traditional methods.

There are certain criteria for a visualization tool to be effective 1) the accuracy and importance of the information being displayed, 2) the clarity by which this information is conveyed to the stakeholder and 3) the user interface which allows the stakeholder to explore the presented information [1]. Some of the general categories in which a visualization environment can be divided are: relationship between different entities in the source code, general flow of the analyzed software, architectural concepts and documentation. Any programmer who is trying to understand a small fragment of the software might need to view the different methods invoked during the start of the program. He might also want the colored flow of these methods during the advancement of the software execution. In addition knowing thread execution information, class loading metrics as well as call trees would be helpful. He would want all of this information available to him from a single tool instead of getting this information from a multitude of sources which would further complicate the process.

Tool Framework

The framework of our tool has some basic areas to denote software architecture visualization: Dynamic Representation (DR), Static Representation (SR) and Navigation and interaction (GUI). For evaluation purposes, Static representation deals with compile time information while Dynamic representation deals with information during runtime of particular software. The Navigation and interaction is the actual User Interface that a stakeholder would use in order to extract and use the information from our tool for particular software. These paradigms are further elaborated in the next section. All of these above paradigms are goals that need to be satisfied in a software architecture visualization tool.

Static Representation

This is the information that can be gathered before runtime, that is, during compile time like data dictionary, source code etc. Our tool gives us information about certain static information regarding the code of a Java program. Sometimes this information is present in a multitude of files around the system and getting it all into a single frame gives the analyst an advantage. Information such as loaded classes, methods, modules etc is important to understand in order to get a complete view of the executing software.

Dynamic Representation

This is the information gathered during the execution of software or during runtime. Such information can be very useful and informative since it provides insight about the resources being used and allotted for particular software to run. Our tool profiles the software running on the Java Virtual Machine (JVM). Jvm allots Heap memory during runtime for the different methods and classes that are executed. This allotment is during runtime of the software and conveys a lot of useful information to the analyst. Other information includes threads running at a particular instance, memory utilization, stack flow information etc. Again this information is not present at a particular spot in the machine but has to be gained from a number of different sources in the machine. One of the important advantages would be to get information even on remote machines. This add-on could be really important on certain occasions since it is quite possible that information is present on different machines. As well as machines on a network might have different configurations and the execution of the software in analysis might have different effect on such machines.

Graphical User Interface and NI

Even though graphical user interfaces are taken lightly while developing a tool, according to the complex working of our tool, the GUI plays a very important role. The analyst of the software would want easy to use as well as a friendly interface so that understanding could be enhanced. Since the tool visualizes different aspects of the software, different colors would be used in order to create a better interface. For example, the methods shown would be revealed in black but would have a red color arrow showing the next method that is called by this method. This would help the analyst to easily see and understand call graphs.

Java Virtual Machine (JVM)

Java Virtual Machine is a complex VM which is considered to be under High Level Language Virtual Machines. It is the reason for the portability of the code written in Java. The JVM is invoked in case of multi-platform programming. Our tool monitors the java programs running in the JVM and thus it is crucial to understand the components that build up a JVM.

Fig 1. Architecture of the Java Virtual Machine [4]

The JVM consists of 4 basic units as shown in fig.1: Execution Unit, OS Virtualization Layer Unit, Memory management Unit, System Services Unit. Since our tool majorly deals with two units, their understanding is necessary:

Memory Management Unit: This area deals with the heap memory allocation, garbage collection, reference handling etc.[4]

System Services Unit: This unit includes different services to the java applications. The thread management component is included in SSU which works according to the specification of the JVM. The class loader is also included in this unit. It is in charge of loading, initializing as well as verifying java classes.

In order to collect data in the JVM certain events were intercepted as shown in Table 2 [4]:


Trigger information


Generated when the Virtual Machine is started


Triggered when the Virtual Machine has terminated


JVM initialization is complete

Thread Start/end

Triggered as soon as the run method is entered for Thread

Monitor Wait/Waited

Triggered Object.wait()

Class Load/Prepare

When the class is loaded when java.lang.class instance is loaded.Table 2 [4]

Related Events in the JVM useful for monitoring purposes

Java Management extension (jmx)

Java Management Extension or JMX, even though largely unknown provides support in order to profile and instrument the code running in the JVM. JMX also provides an API to instrument the virtual machine running on a remote machine. Certain interfaces known as Managed Beans (MBean) are used in order to gain instrumentation. MBeans are like java objects that can be created, but have to be registered in the platform MBeans server. A console can then be connected to this server in order to instrument the application running in the Java Virtual Machine. An MBean is made up of a set of operations that can be invoked as well as read/write attribute. Each of these platform MBean comprises of operations like thread information, memory utilization and garbage collection [9]

Fig. 2 [8]

Architecture of Our Tool Connecting with JVM

Components of the tool

The tool consists of two major components:


In order to profile or extract data from an application running at the local JVM (Java Virtual Machine) , it is very important to construct a program that can actually connect to a local JVM. This program is also referred to as the Agent. Agent is the most critical part of my project. The agent captures the state of the JVM and extracts packages, methods etc from the user input application.



Provides i/p and o/p

Management interface for monitoring JVM

Core classes for JMX

Api to attach to JVMTable 3 [7]

Packages used for Agent component


Console is the Graphical User Interface of the project. It collects data from the agent and shows it as the output in a visual format.


Software architecture is a very large entity by itself and visualizing it through a tool gives a lot of insight about the resources used by it. All of stake holders through the different levels of the software development life cycle would be able to take advantage of this visualization tool. Further research can be made in making the tool connect to remote machines and thus access the JVM running in those computers. Our research also includes a very important part of the Java programming language which is Java Management Extension. Use of JMX is still in the dark but its usefulness can be studied and applied for further developing of the products