BPF Performance Tools Chapter 12 — Languages.

BPF can trace any program — but "trace your code" means very different work depending on whether the language is compiled, JIT-ed, or interpreted. The wall everyone hits is the same: stacks full of hex addresses or interpreter internals instead of your function names. Solving that — symbols and stack walking, per language — is most of the battle. This chapter is the per-language playbook: what works out of the box, what needs a symbol map, and what needs the runtime's own probes.

01 Three ways code runs, three tracing problems

The tracing difficulty follows the execution model. Compiled languages produce native machine code with (ideally) symbols — BPF's uprobes and stack walkers work directly. JIT runtimes compile to native code at runtime, so the machine code exists but has no static symbol table — you must supply a map from address to method name. Interpreted languages never compile your code to native at all; the CPU executes the interpreter loop, so a native stack shows the interpreter's frames, not yours. Knowing which model you're in tells you exactly which problem you'll face.

02 Compiled languages: C, C++, Go, Rust

The easy case. Native binaries can be traced with uprobes on any function, and stacks work — provided two things: frame pointers (so the stack can be walked) and symbols (so addresses resolve to names). The recurring pitfall (Chapter 2) is binaries built with -fomit-frame-pointer, which breaks walking; rebuild with frame pointers or use DWARF/LBR unwinding. Go has its own quirks (goroutines, its own stack management) but is broadly traceable. Once symbols and frame pointers are sorted, compiled-language profiling and function tracing with BPF works exactly as the CPU and application chapters described.

03 JIT languages: Java, Node.js

JIT runtimes compile bytecode to native code on the fly, so the methods are native — but their addresses aren't in any static symbol table, so a flame graph shows raw hex for your hottest methods. The fix is a symbol map: a helper (e.g. perf-map-agent for Java, Node's --perf-basic-prof) writes a /tmp/perf-PID.map file mapping JIT addresses to method names, which BPF/perf read to label stacks. With that in place you get full Java/Node flame graphs. You also need frame pointers preserved through the JIT (e.g. the JVM's -XX:+PreserveFramePointer) or stacks break — a JVM-specific gotcha.

04 Interpreted languages: Python, Ruby, bash

The hardest case. Your Python function never becomes native code — the CPython interpreter executes bytecode in a big eval loop, so a native stack shows PyEval_EvalFrameEx and friends, not your functions. To see your code you need language-specific instrumentation: many runtimes ship USDT probes (Python's function__entry, Ruby's method probes) that fire on language-level events, and there are tools that walk the interpreter's own frame structures. bashreadline, for instance, traces shell commands by hooking bash's readline. Without these, BPF can still tell you the interpreter is hot, but not which of your functions — a partial answer.

05 The u* tools for runtimes

BCC ships a family of language-runtime tools (prefixed u) driven by USDT probes the runtimes expose. ucalls counts method calls (or summarizes their latency) by language. uflow traces method entry/exit as a flow (a call trace). ugc traces garbage-collection events and their duration — invaluable for correlating latency spikes with GC pauses (the runtime effect from Systems Performance). uobjnew tracks object allocation by type; uthreads traces thread creation; ustat summarizes runtime stats. They work across Java, Python, Ruby, Node, and more — wherever the USDT probes exist — giving language-aware visibility without per-language custom code.

06 GC: a common culprit

Managed runtimes reclaim memory automatically, and garbage collection pauses are a frequent, mysterious source of tail latency — a request that's normally 20 ms suddenly takes 300 ms because a stop-the-world GC ran. ugc traces GC events and durations, letting you confirm whether a latency spike lines up with a collection. This is the BPF way to test the GC hypothesis directly rather than guessing from runtime logs. Combined with allocation tracing (uobjnew), you can connect what allocates heavily to when the GC pauses — pointing at the code creating the garbage.

07 USDT probes and custom tracing

USDT (User Statically-Defined Tracing) probes are the bridge for non-native code. Many runtimes and applications ship them — stable, named events like "method entry," "GC start," "query executed" — that BPF can attach to with predictable semantics across versions (unlike uprobes on internal functions). List them with bpftrace -l 'usdt:/path/to/runtime:*' or tplist. When the u* tools don't cover your question, a bpftrace one-liner on the right USDT probe often does, giving language-level visibility (which method, which query) without grappling with the interpreter's internals or the JIT's symbol gaps.

08 A per-language workflow

(1) Identify the execution model — compiled, JIT, or interpreted. (2) Compiled: ensure frame pointers + symbols, then uprobe/profile as normal. (3) JIT: set up a symbol map (perf-map-agent / --perf-basic-prof) and preserve frame pointers in the runtime, then profile for flame graphs. (4) Interpreted: use USDT probes and the u* tools (or interpreter-aware tools) — don't expect native stacks to show your code. (5) For managed runtimes, check ugc for GC-pause latency. (6) Reach for USDT one-liners when the canned tools don't fit. Match technique to model; fix stacks first.

09 Questions engineers actually ask

10 Key takeaways

• Tracing difficulty follows the execution model — compiled, JIT, or interpreted.
• Compiled: uprobe/profile directly, but need frame pointers + symbols.
• JIT (Java/Node): need a symbol map (perf-map-agent / --perf-basic-prof) and preserved frame pointers.
• Interpreted (Python/bash): native stacks show the interpreter, not your code — use USDT/runtime tools.
• The u* tools (ucalls, uflow, ugc, uobjnew...) give language-aware visibility via USDT.
• ugc confirms GC-pause latency — a common mysterious tail-latency cause.
• Diagnose missing stacks by model; fix symbols/stacks before anything else.

11 Wrapping up

Tracing a language is mostly about recovering your function names from the way the code reaches the CPU: symbols and frame pointers for compiled, a symbol map for JIT, runtime USDT for interpreted — with ugc and friends giving language-aware insight. Get the stacks right and the rest of the toolkit applies. Next we move up to whole-application tracing — requests, threads, and locks. Next: Applications.