DocumentationAeminiumRuntimeProfiler - Revision history

Aeminium: /* Running an Application */

2012-02-21T10:50:48Z

‎Running an Application

Aeminium: /* IMPORTANT NOTE */

2012-02-18T17:29:47Z

‎IMPORTANT NOTE

Aeminium: /* The profiler package */

2012-02-18T17:27:10Z

‎The profiler package

Aeminium: /* CountersProbe (Telemetry Data) */

2012-02-18T17:14:01Z

‎CountersProbe (Telemetry Data)

Aeminium: /* CountersProbe (Telemetry Data) */

2012-02-18T17:13:26Z

‎CountersProbe (Telemetry Data)

Aeminium: /* The profiler package */

2012-02-18T17:12:29Z

‎The profiler package

Aeminium: /* The profiler package */

2012-02-18T17:11:11Z

‎The profiler package

Aeminium: /* JProfiler Classes */

2012-02-18T17:05:35Z

‎JProfiler Classes

Aeminium: /* JProfiler Classes */

2012-02-18T17:05:12Z

‎JProfiler Classes

Aeminium at 17:03, 18 February 2012

2012-02-18T17:03:57Z

@@ Line 8: / Line 8: @@
 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/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''
+  java -agentpath:/home/username/Tools/jprofiler7/bin/linux-x64/libjprofilerti.so=port=8849 -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''
 This will allow you monitoring the Runtime activity on online mode, requiring you to start a new session at JProfiler, listening in the port 8849. The meaning of the flags are the following:
@@ Line 21: / Line 21: @@
 As for offline mode, use the following command:
-  java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652,<br>config=/home/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''
+  java -agentpath:/home/jprofiler7/bin/linux-x64/libjprofilerti.so=offline,id=3652,<br>config=/home/username/Tools/jprofiler7_scripts/config.xml -Djprofiler.probeProvider=aeminium.runtime.profiler.AeminiumProbeProvider -jar Fibonnaci.jar''
 To know more about the 'config.xml' file, check the [http://resources.ej-technologies.com/jprofiler/help/doc/help.pdf JProfiler documentation].

← Older revision		Revision as of 17:29, 18 February 2012
Line 1:		Line 1:
−	~~== IMPORTANT NOTE ==~~
−	~~This page is still under construction, so the text might eventually be reviewed.~~
−
	== Preparing the ground ==		== Preparing the ground ==

@@ Line 95: / Line 95: @@
 # 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 next step, is exactly the same, but now, we will doing the profiling for the graph variables.
+# The next 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 (Method Interception)===
-The use the JProfiler method interception for controlling the time the task spend at each state. As each task change it's state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), we only intercept method entrances, because at this point, we know that the previous state is over and new one is starting.
+Our Profiler uses JProfiler method interception for controlling the time every task spend at each state. We take advantage of the fact that tasks change theirs state at the beginning of a method (for example, the task turns into the state RUNNING when the method invoke() is called), and so, we only intercept method entrances.
-Firstly, we need to define all the method to intercept at the method getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.
+Firstly, we need to define all the method to intercept at the getInterceptionMethods(). As stated in the JProfiler API Javadocs, for the class [ftp://202.127.19.60/home/ddg2/chenting/jprofiler5/api/javadoc/com/jprofiler/api/agent/interceptor/InterceptionMethod.html InterceptionMethod], it is used the JVM's representation of type signatures for both argument type and return type.
 Once you have defined all the methods to be intercepted, it's time to handle them at the interceptionEnter(). As said before, we can do all the work by only intercepting the entries, and therefore, we leave the interceptionExit() untouched.
-At this point, we take a systematic and quite simple procedure. At the entry of a method, we pick the payload from the hashtable reserved tot he old state, passing it afterwards to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a given state.
+Let's now take a look at the interception mechanism. To achieve the time measuring, we use a systematic and quite simple procedure, which is aided by auxiliary hashtables, one for each state a task can assume. The hashtables will hold payloads, which save the time of their creation.
-When this is done, a new payload info must be created and stored in the corresponding hashtable, so the next method interception can use it as described in the first step. This second step marks the starting time of a new state.
-Naturally, this procedure is different for for the methods addTask() and taskCompleted(), as they correspond to the beginning of the first useful state (WAITING_FOR_DEPENDENCIES) and the end of the last (WAITING_FOR_CHILDREN). For them, we can only insert a new payload info or remove it from the hashtable.
+At the entry of a method, we have two states to consider. The one a thread has at the moment, the old state, and another, which is the state this task will change to. We get the payload from the old state's hashtable, passing it to the InterceptorContext, which will calculate the difference between the creation time and the current time. This will define the time this task has spent at a that state.

@@ Line 95: / Line 95: @@
 # 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 next, is exactly the same, but now, we will doing the profiling for the graph variables.
+# The next 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.

@@ Line 92: / Line 92: @@
 For collecting data, the method fillTelemetryData() is executed, going through the following steps:
-# 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().
+# Firstly, as stated before, a instance of the class DataCollection is created.
-# 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.
+# Then, after checking if the scheduler reference is not null, we simply call the method collectData().
-#At the end, the array will be completely full and it's up to the JProfiler to display the graphs.
+# 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.
 === TaskDetailsProbe (Method Interception)===

@@ Line 73: / Line 73: @@
 === 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.
+AeminiumProbeProvider is a simple class that let's JProfiler know which are the probe classes present in the project that are going to be used for profiling. It merely 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 (Telemetry Data) ===
-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 CounterProbe is responsible for monitoring the global task activity for the scheduler and graph. By global task activity, we mean, for example, the number of completed tasks or how many tasks marked as running at a given moment.
 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:
@@ Line 89: / Line 89: @@
 }
-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.
+This second group separates by the values by each working thread, whose number is defined by the value in 'maxParallelism'.
-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.
+For collecting data, the method fillTelemetryData() is executed, going through the following steps:
 At the end, the array will be completely full and it's up to the JProfiler to display the graphs.

@@ Line 69: / Line 69: @@
 ===<span style="color:#8B0000"> JProfiler Classes</span>===
-The three classes left for analyzis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.
+The three classes left for analysis are the ones which are required by JProfiler to collect telemetry information, as well as handle method interception.
 === AeminiumProbeProvider ===

@@ Line 36: / Line 36: @@
 === 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.
+This class was created so we could statically refer the scheduler and the graph. This extra step is necessary because the JProfiler classes must use a fixed constructor and are initialized by the JProfiler itself. Therefore, we couldn't pass, for instance, 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.
+To accomplish this goal, the class AeminiumProfiler is initialized by the Runtime at start time and whenever JProfiler needs to collect data from the scheduler or the graph, it simply has to pick the AeminiumProfiler's references. In order to avoid ''null'' values (if the JProfiler starts sampling before the Runtime is fully ready), it's wise to always double check the contents of the 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.
+The DataCollection works like a structure that will hold all the variables to profile. At each measurement, the JProfiler passes an instance of this class to the scheduler and then to the graph, being these two components responsible for filling the fields that are related to them.
-Therefore, it contains the following variables:
+Therefore, DataCollection contains the following variables:
 ===== Scheduler variables =====
@@ Line 52: / Line 52: @@
 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.
+In most cases, we will also have more than a single working thread. Besides it, there are three different types of tasks too, namely Atomic, Non-blocking and Blocking tasks. 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 =====