cc-truffle-performance-plugin

Dumps and analyzes Graal IR compiler graphs showing optimization decisions. Use BGV format with bgv2json/seafoam to inspect escape analysis, boxing removal, inlining decisions, and call node types. Reveals what compiler actually optimized vs intended. Use as last resort after basic profiling when root cause remains unclear. (project)

Traces deoptimization events where execution falls back from compiled code to interpreter. Use to detect deoptimization loops, unstable assumptions, and type instability. Zero transfers in steady-state is the goal. Many transfers indicate severe performance problems. Critical for diagnosing compilation instability. (project)

Detects optimization barriers during Truffle compilation. Identifies virtual calls, non-constant stores, unresolved type checks, and TruffleBoundary issues that prevent peak performance. Reports exact source locations with stack traces. Use as essential step for eliminating compilation warnings. ONLY works with traditional Truffle DSL nodes (NOT Bytecode DSL). (project)

Establishes performance baselines by analyzing language characteristics, querying Computer Language Benchmarks Game and AreWeFastYet for comparable languages, creating local benchmark implementations, and generating a comprehensive baseline report. Use before performance optimization to set realistic expectations. Use when starting performance work, need benchmarks, want to compare against other languages, or establish expected performance ranges. (project)

Fetches information from official GraalVM, Truffle, and Graal compiler documentation for API guidance, performance optimization, compiler flags, profiling, specializations, Bytecode DSL, Truffle DSL, partial evaluation, and compilation analysis. Use when you need authoritative documentation about Truffle framework, GraalVM compiler options, or optimization techniques. Use when asking about Truffle API, compiler flags, specialization patterns, or Graal options. (project)

Compiles verified performance findings into structured analysis reports. Creates prioritized issue lists with quantitative evidence from profiling tools. Use after theories have been verified to produce final documentation. Use when creating performance report, documenting findings, or summarizing optimization opportunities. (project)

Analyzes Truffle language implementations to generate testable performance theories. Loads benchmark baselines, performs systematic code analysis, and produces prioritized hypotheses with verification plans. Use after establishing baseline to identify potential performance issues before profiling. Use when analyzing why code is slow, finding optimization opportunities, or planning performance investigation. (project)

Experimental allocation profiler tracking memory allocations at guest-language level. Shows allocation sites, object types, and memory pressure patterns. Use to identify allocation-heavy locations, find unnecessary object creation, and understand memory behavior. High allocations in hot loops = optimization opportunity if escape analysis isn't eliminating them. (project)

Time-based sampling profiler showing WHERE execution time is spent (wall-clock time, not frequency). Provides histogram with self/total time, compilation tiers (T0/T1/T2), and flame graphs. Use as FIRST step to identify hot functions consuming most time. Low overhead, suitable for longer runs. Pair with tracing-execution-counts to understand time-per-execution vs execution frequency. (project)

Logs every compilation event with timing, tier (T1/T2), success/failure, and invalidation reasons. Use to verify hot code is compiling, diagnose compilation failures/bailouts, track recompilation cycles, and understand tiered compilation behavior. Shows WHEN compilation happens. Combine with detecting-performance-warnings to understand WHY compilation fails. (project)

Counts exact execution frequencies (not time) at function/statement level. Shows interpreted vs compiled execution split. Use to verify functions compile (>95% compiled), understand control flow patterns, and validate algorithmic complexity. Complements profiling-with-cpu-sampler by showing frequency rather than duration. (project)

Shows inlining decisions during compilation with call tree and reasons for inline/don't-inline. Use to verify critical calls are inlined, understand why inlining failed (too large, recursive, boundary), and optimize method sizes. Good inlining = better compilation. Recursive functions show 'not inlined' - expected behavior for Bytecode DSL limitation. (project)

Coordinates verification of performance theories using profiling tools. Enforces Fermi verification protocol, runs appropriate tool skills, and synthesizes evidence from multiple sources. Use after generating theories to prove which issues actually matter. Use when validating hypotheses, running profiling tools systematically, or collecting quantitative evidence. (project)