Versions Compared

Old Version 24

changes.mady.by.user ssiegl (Unlicensed)

Saved on

compared with

New Version 25

changes.mady.by.user ssiegl (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Level

Section

Description

Link to the discussion of unique identification

1

Platform

The platform the agent is running on.

IS platform identification

2

JVM

On each platform can be multiple JVMs

IS JVM identification

3

"Thread"

Within each JVM different threads are run

IS thread identification

4

method

Within one thread a method can be invoked multiple times

 

...

  • Each invocation of a method checks if an invocation sequence is currently active
  • The staging area builds up a stack of all methods that are invoked within one "thread"
  • The data is sent to the CMR. Based on the JVM identification, the platform identification and the thread identification, the CMR can extend its stack of the methods of one invocation by adding the received stack to it. If no information is currently available, the CMR must assume that this was a new invocation.

...

Invocations within one thread are saved as a stack that is unique per thread identification. The invocation of an instrumented method within an invocation sequence will create two different information objects:

...

  • The creation of a Runnable is an additional event that can be added to the
  • We need to instrument the creation of a Runnable object and provide the following information
    • the current thread identification of the current thread that created the Runnable
    • the counter of how many asynchronous calls were already started within this thread

...

ID

unique across

Buildup

method invocation identification

  • at least within one invocation sequence
  • within on thread on one jvm
  • two calls to the same method must result in different ids

static counter
(within the same classloader static is safe -> is there a possibility that objects/classes within one thread are loaded by a different branch of a classloader hierarchy)

invocation sequence identification

  • everything (JVM, thread)

JVM_ID + Thread ID
thread id is not unique (thread pools!)

  • 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

...