This page contains the solution approaches that were discussed in the master thesis.
...
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 This way, the current executed method is always on top of the stack.
Each thread has a private stack containing its frames.
...
Java Stack Trace approach
TODO: Describe approachThis approach uses the JVM's method stack to get the necessary information from it and form the order in which the methods are stored.
Disadvantages:
- Slow (suboptimal implementation of getStackTrace())
- High memory consumption ( method calls can go very deep)
- There is a possibility that a JVM implementation does not provide this stack, since its not part of the JVM Specification
Own Stack Trace approach
TODO: Describe approach Use own implementation of the method stack, to make it more reliable and solve the getStackTrace() performance issue.
Disadvantages:
- High memory consumption
- Slow (each method has to do a pop and push)
...
An additional parameter is defined, that would be passed to each child method.
With this parameter information about the invocation trace is inherited.
Disadvantages:
- High effort to change the native method signatures
...
Method-ID approach
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 --->
...