allocation-profilinglisted

# Allocation Profiling Find which code produces heap bytes, decide whether those bytes are avoidable, and test whether reducing them improves the reported problem. Allocation is neither retained heap nor GC cost. A large allocation site is a candidate, not automatically the cause of latency. The reference baseline is OpenJDK 25 GA and async-profiler 4.1, not a minimum target version. Before version-sensitive advice, inspect Maven/Gradle release and toolchain settings, resolved logging/profiler dependencies, CI/runtime images and actual JVM flags. Keep the project's Java and dependency versions; using this skill does not authorize upgrades or enabling preview/experimental features. HotSpot-specific events and flags are not portable Java guarantees. ## Workflow 1. **Define the comparison.** Record the JDK build, collector, heap and relevant flags, profiler version, workload/payload mix, concurrency, warm-up state, affected time window, and target metric. Request missing facts that change the tool or decision. With source alone, provide a hypothesis and collection plan; do not invent a rate or confirmed fix. 2. **Establish the rate and denominator.** Prefer existing counters or a recording from the affected window. Report bytes/s and bytes/completed operation when that denominator is meaningful; account for background work and failed requests. Compare like workloads. GC-log Eden consumption is only an estimate of young allocation and can miss direct-old