Add LuaJIT interpreter on latest main

[dalehamel]

LuaJIT unwinder patches for production ingress-nginx

Cherry-pick of upstream PR #1236 plus Shopify-specific fixes, tested on production ingress-nginx nodes with OpenResty/LuaJIT.

Production testing results (2026-04-24)

The upstream LuaJIT unwinder works. Profiles flow correctly including Lua-level frames. Our initial zero-sample issue was caused by our ingestion side (missing "luajit" frame kind in the clickhouse sink), not by the unwinder itself. That ingestion fix shipped separately.

We ran A/B/C tests on the same production ingress-nginx node (routing-us-ce1-ej9) with three variants:

• A (upstream baseline): profiles flow, but ENOSPC errors in logs and ERROR_4012 error frames in output
• B (buffer fix only): ENOSPC errors eliminated, ~2x sample count
• C (all fixes): visually identical to B — GCproto pre-caching did not produce a visible difference

Commits

Commit	Purpose	Upstream-relevant?
adb5329	Fix arm64 lint/test drift from cherry-pick	✅ Yes
4148ca4	eBPF verifier fix (FRAMES_PER_WALK 15→8) for kernels ≥6.16	✅ Yes
c1dc372	Raise pidPageMappingInfoSize 1M→4M — eliminates ENOSPC log spam at scale	✅ Yes (main fix)
4e5b14a	Degraded GCproto fallback — extract chunkname when debug pointers stale	❌ Non-critical
8b57f24	GCproto pre-caching via GCtrace.startpt	❌ Non-critical

Only c1dc372 (buffer raise) produced a measurable difference in production testing. The GCproto patches are informational improvements that did not visibly change the flamegraph output.

Upstream comment

Full write-up with log evidence posted on the upstream PR:
open-telemetry#1236 (comment)

Related PRs

• PR #43 — upstream cherry-pick base (target for this PR)

[dalehamel]

I kept running into issues:

{"time":"2026-04-23T22:48:27.124374999Z","level":"ERROR","msg":"Error adding trace(5876): update: no space left on device"}
{"time":"2026-04-23T22:48:27.124381043Z","level":"ERROR","msg":"Error adding trace(1569): update: no space left on device"}
{"time":"2026-04-23T22:48:27.12438688Z","level":"ERROR","msg":"Error adding trace(3960): update: no space left on device"}
{"time":"2026-04-23T22:48:27.124393159Z","level":"ERROR","msg":"Error adding trace(4096): update: no space left on device"}
{"time":"2026-04-23T22:48:27.124399773Z","level":"ERROR","msg":"Error adding trace(5250): update: no space left on device"}
{"time":"2026-04-23T22:48:27.12440761Z","level":"ERROR","msg":"Error adding trace(6331): update: no space left on device"}

I haven't had time to deep dive on it yet but I threw gpt 5.4 at it and I'm trying to get it to tweak things until it works.

I suspect that the amount of traffic the load balancer gets is probably causing some buffer to fill faster than in gets drained.

If I can get things working I'll comment on the upstream PR.

[dalehamel]

The profiler binary and OTLP reporter work fine — the gRPC connection is established and the report loop runs. The problem is upstream of the reporter: zero samples ever arrive at ReportTraceEvent.                           
                                                                                                                                                                                                                                 
 Here's the chain:                                                                                                                                                                                                               
                                                                                                                                                                                                                                 
 1. LuaJIT trace mapping sync consumes the pid_page_to_mapping_info BPF map. Each nginx worker has ~6,500-7,000 JIT traces generating ~65,000 LPM prefixes. With 20+ nginx workers, the first 7-8 workers exhaust the map's      
 524,288-entry soft limit (half of 1M max_entries).                                                                                                                                                                              
 2. All subsequent processes — including the remaining nginx workers — fail to insert their dummy PID entry via processNewMapping → UpdatePidPageMappingInfo. The log shows this clearly: ERROR_4012: native_no_pid_page_mapping 
  means the eBPF tracer saw a sample from a PID it doesn't recognize.                                                                                                                                                            
 3. Without the dummy entry, the eBPF perf program drops the sample entirely — it never reaches the userspace perf buffer, so ReportTraceEvent is never called, and the OTLP reporter sends empty batches (which it silently     
 skips at Debug log level).                                    

Scale issue i guess

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.