...
...
...
...
Other tracing approaches: TODO: Move to child page
Method Invocations in JVM
In Java the current executed methods are represented as frames, that are stored on a stack. Each frame contains all information that an invocation tracer might need.
When a method is started, it's frame is put on the stack and when it is done the associated frame is removed from the stack. In this way, the current executed method is always on top of the stack.
Each thread has a private stack containing its frames.
This could be used for tracking the method invocations in Java. But the stacks and it's frames not accessible from Java itself and it would be necessary to use an extension library written in C. This is not acceptable, since it would go against the non-functional requirements and make the tracer platform dependent.
Method-ID
Quote:
"Another possibility to realize the invocation tracer is to add unique identifiers to all available sensors, so that every sensor gets an additional thread Id and a continuous node number in a call tree. This way, the process of building a complete Context Call Tree is divided in several parts: the sensors provide small pieces of information and some kind of tree builder has to provide a basic functionality to connect the gathered values and build a complete context tree out of this multiple node information."---->Not sure if i understood it right...
Each thread gets an unique ID and an continuous number for each method invocation done by this thread. This way each invocation can be associated with its thread.
...
Approach picket in the thesis for the prototype
Each thread gets a stack, where current active methods are stored. Only monitored methods are considered for the stack.
Asynchronous method calls are connected to these stack elements.
The invocation data is send to the server in small pieces, on every method entry and exit. This way there is no need to store the data until the method finishes, what reduce the stress on the target application. The network has to handle smaller packs, which is also good for the performance. Also the server has the possibility to process the data earlier and it can be displayed while the method is still executing.
...
This page describes all problems, tasks and solution approaches regarding tracing of method invocations in the same thread.
Main topics
How to access information about the current method in a reliable way?
- How to associate a called method with it's caller?
- How to collect and filter the invocation information without much overhead on the target application and network?
- Can the amount of data from the agent be reduced? Can it be aggregated?
Current solution (state)
(Previous solution approaches regarding this topic were already discussed in the master thesis.)
Currently the sequence sensor is implemented as a container, which collects all sensor data (e.g. from timer sensorsensors) data starting from an defined start point (execution of a predefined method).
This collected data is chronologically ordered, to allow to trace the invocation sequence.But this
Disadvantage:
This is not suitable for asynchronous methods. TODO: Validate if this is the current state of the sequence sensor. Possibly there were improvements in the meantime.
(Also see continues sending in IS advanced notes for better understanding)
New approaches / idea
Idea:
On each hook, the Id of the currentThread would be acquired. So it could be saved when an method was executed by what thread.
(How much overhead would this generate?)
Questions / Possible Problems
- Do we have to modify the ClassLoaders and therefore keep them thread safe?
- Do we have to modify Java core classes?
- Which JVM implementations (e.g Sun JVM/ Sun Open JVM/ BEA JRockit/ Kaffe) can Javassist instrument or can be used on? (Is Javassist really platform independent?)
- What when Javassist does not work on a JVM?
- How to handle cascaded methods, when some in the middle are not monitored? M1>>M2>>M3>> but M2 not instrumented.
From Braindumb in IS Advanced
Each thread has a unique number (per JVM) automatically assigned.
- But threads can and - in fact are - reused. For example thread pools do not instantiate new threads, but instead pass different Runnable instances to the existing threads. Each different runnable is itself a different functionality. Thus the thread ID cannot be safely used for identification