Difference between revisions of "DocumentationAeminiumRuntimeProfiler"

Revision as of 22:32, 12 February 2012

Preparing the ground

Downloads

The Profiler uses the JProfiler framework to collect and manage all the information concerning the performance of the Æminium Runtime. Also, considering consulting the JProfiler documentation whenever you have a doubt which isn't covered in this page.

Running an Application

To run an application along with the JProfiler, you must add a few flags before executing the 'java' command, namely the '-agentpath' and '-Djprofiler.probeProvider', as described in the example bellow for Linux 32-bit:

java -agentpath:/home/alcides/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar

• The '-agentpath' flags tells the JVM the location of the 'jprofilerti library', which is usually located the folder where JProfiler was installed.

• In Windows 32-bit, you can try '-agentpath:"C:\Program Files\jprofiler7\bin\windows\jprofilerti.dll=port=8849"'. For more information, look in the section 'B.3.10 Starting Remote Sessions' of the JProfiler documentation.

• The '-Djprofiler.probeProvider' will tell the JVM the class path to the probe provider, a class whose contents are discussed below.

The profiler package

The first two classes are regular Java classes, which were created just to make easier the process of collecting the profiling information.

AeminiumProfiler

This class was created so we could statically refer the scheduler and the graph. This is necessary because the JProfiler classes must follow a strict constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for the example, the Runtime as an argument to the probe providers. To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references.

DataCollection

The DataCollection works like a structure that will hold all the variables to profile. At each measuring, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these components responsible for filling with values the fields that are related to them. Therefore, it contains the following variables:

Scheduler variables

• public int noOccupiedQueues;
• public int [] taskInNonBlockingQueue;
• public int taskInBlockingQueue;
• public int [][] tasksHandled;

We may have more than one non-blocking queue, and hence the array for this variable. In most cases, we will have more than a single working thread. Also, there is also three different types of tasks, namely Atomic, Non-blocking and Blocking. Due to this two conditions, we need a matrix to store all the information about how many tasks were handled by each thread.

Graph variables

• public int noTasksCompleted[];
• public int noUnscheduledTasks;
• public int noWaitingForChildrenTasks;
• public int noWaitingForDependenciesTasks;
• public int noTasksWaitingInQueue;
• public int noRunningTasks;
• public int noCompletedTasks;

The number of tasks completed must be array because, as above, we have three different types of tasks.

JProfiler Classes

The three other classes that also belong to the profiler package are the ones which are required by JProfiler to collect telemetries information, as well as handle method interception.

AeminiumProbeProvider

AeminiumProbeProvider tells JProfiler which are the probe classes present in the project which should be used for profiling. It simply contains a method, getProbes(), which return an array with the necessary probe classes. In the Æminium Runtime, those will be CountersProbe and TaskDetailsProbe, discussed right away.

CountersProbe

The CounterProbe is responsible for monitoring the global variables related to the scheduler and graph. By global variables, we mean, for example, the number of tasks that were completed so far or how many tasks are marked as running at a given time.

The variables to collect are defined in the method getMetaData(). The first group of variables correspond to the sum of the values of all the active threads. Then, you have a second group, which is defined inside the following 'for' cycle:

1 for (int i = 0; i < maxParallelism; i++)
2 {
3     metaData.addCustomTelemetry("Tasks in Non-blocking Queue (" + (i + 1) + ")", Unit.PLAIN, 1f);
4     metaData.addCustomTelemetry("No of Atomic Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
5     metaData.addCustomTelemetry("No of Blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
6     metaData.addCustomTelemetry("No of Non-blocking Tasks Handled (" + (i + 1) + ")", Unit.PLAIN, 1f);
7 }

The Java variable 'maxParallelism' correspond to the number of active threads in the Æminium Runtime and so, we will have profiling variables separated by each thread.

For collecting data, the method fillTelemetryData() is executed. As stated before, a instance of the class DataCollection is created. Then, after checking if the scheduler reference is not null, we simply call the method collectData(). At this point, the DataCollection object will have all the information coming from the scheduler, so it's only a matter of filling up the 'customTelemetries' array with the correct values. The second step, is exactly the same, but now, we will doing the profiling for the graph variables. At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

TaskDetailsProbe

The class