This page contains the solution approaches that were discussed in the master thesis.

Previous inner-Thread tracing approaches 

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. 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.

Disadvantages:

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.

Java Stack Trace approach

This 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

 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)

Method Signature approach

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

Container approach

See current solution (state).

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."

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 (mixed approach)

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.

For better understanding see Inner-Thread(IS notes), Implementation Tracing Agent and Runnable Variables approach.

Approach from brain dumb

• Active pushing of invocation sequence id from one thread to another
  
  • hard to realize: how do we know that the next method instrumented will be invoked in a new thread
  • at this point in time threadlocal information of the caller is no longer available
  • It would be necessary to extend the method signature of all methods of all classes that inherit Thread / Runnable with an additional information (the invocation sequence) ... still very unclear
• Alternative would be to use JVM wide identification of the invocation sequence id with the respective thread

Brain dump:

Possible approach for continues Sending:

Analog to the container method, but the sending of information would be triggered  for example after each 5 method closure. 
To distinguish the method invocations done by the current thread from this done by other threads, each thread\runnable would get an ID(Remember thread pools and runnable reuse).