Browse Prior Art Database

Method and Apparatus for Dynamic Inclusion of Profiling Functionality's in Java Classes

IP.com Disclosure Number: IPCOM000024639D
Original Publication Date: 2004-Apr-02
Included in the Prior Art Database: 2004-Apr-02
Document File: 5 page(s) / 133K

Publishing Venue

IBM

Abstract

This article describes a method and apparatus for dynamically enabling profiling capabilities in Java classes by inserting byte code during class loading. More specifically, we describe the classloading infrastructure that is already available in IBM WebSphere Application Server and show how we have leveraged it to provide the ability to include profiling functionalities in the Java classes that are being loaded at run-time.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Page 1 of 5

Method and Apparatus for Dynamic Inclusion of Profiling Functionality's in Java Classes

Introduction

The ideas that we are going to describe are first and foremost motivated by our performance work at the WebSphere Application Server performance team. Our work involves measurement and profiling of the Trade application on our application server (as well as industry standard workload such as SPECjAppServer2002) using third party tools such as JProbe, OptimizeIt, Wily, etc. The problem with these tools, however, is that they are for the most part very intrusive. They also affect the performance of the application being profiled itself since many of them use JVMPI to get profiling information from the JVM. Therefore, these perturbations skews the real performance characteristics of the application being profiled. Finally, these performance tools are sometimes unreliable, and to some degree non-functional, when subjected to very high workload.

A clever solution that we came up with is to use the existing class loading infrastructure that is already available in WebSphere and extended it to provide an implementation of a framework that will allow someone to insert bytecode into classes that are being loaded. These bytecode can be intended to do about anything but our point of interest, which we also believe is the most useful usage scenario, is inserting profiling logic into these classes. This article will describe the framework in greater details.

Java Class loaders

We provide some basic concepts in Java class loading to set the stage for the framework that we will describe later.

A class is loaded into the JVM when an instance of that class needs to be created. Since a class definition may involve other classes such as a reference to another class, class loading may take place recursively for different classes that are not yet loaded. Classes are loaded through the class loaders which come in two flavors. The first type is the bootstrap class loader - sometimes referred to as the primordial class loader and the other is the user-defined class loader - sometimes referred to as a custom class loader. The bootstrap class loader is built in to the JVM and is responsible for loading trusted classes, e.g. basic Java class library classes, and other classes that are specified in the bootstrap classpath. User-defined class loaders, on the other hand, are not intrinsic components of the JVM. They are subclasses of the java.util.ClassLoader class that are compiled and instantiated just like any other Java class. User-defined class loaders are written so that they can be specialized to provide different loading policies. For example, a class loader might cache binary representations of classes and interfaces, prefetch them based on expected usage, or load a group of related classes together, etc.

Several classloaders may exist in the JVM but a delegation model is used which was introduced in Java 2 starting with version 1.2. In this model, cla...