Part of #44 .
Implements the communication from Otel to the profiling host agent from the spec:
Whenever the active span changes, it's trace context is written to a native thread_local
On start, general service information (e.g. service name) is written to a native global variable
Because the thread_local update can happen very frequently (on every Otel context change), I've added a microbenchmark to prove the production-readiness:
Benchmarks were executed on My MacBook M1 Pro with OpenJDK 21.0.1
The overhead per context activation/deactivation pair where the span changes is around 100ns
Fun-fact: Based on profiling data most (70%) of the overhead comes from converting the string hex-IDs to binary IDs
If the active span doesn't change (e.g. just a baggage update) the overhead is close to zero
Part of #44 . Implements the communication from Otel to the profiling host agent from the spec:
thread_localBecause the
thread_localupdate can happen very frequently (on every Otel context change), I've added a microbenchmark to prove the production-readiness: