[jira] [Updated] (SPARK-56908) Reduce the size of code generated by whole-stage codegen

["Gengliang Wang (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SPARK-56908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gengliang Wang updated SPARK-56908:
-----------------------------------
    Summary: Reduce the size of code generated by whole-stage codegen  (was: Reduce generated Java size in whole-stage codegen)

> Reduce the size of code generated by whole-stage codegen
> --------------------------------------------------------
>
>                 Key: SPARK-56908
>                 URL: https://issues.apache.org/jira/browse/SPARK-56908
>             Project: Spark
>          Issue Type: Umbrella
>          Components: SQL
>    Affects Versions: 4.3.0
>            Reporter: Gengliang Wang
>            Priority: Major
>              Labels: pull-request-available
>
> Whole-stage codegen generates a fresh Java class per stage. Across many operators the generated source contains (a) boilerplate that is type-independent across stages and can be deduplicated into static Java helpers, and (b) branches or variables that are statically dead at codegen time but emitted anyway.
> These patterns cost us in three places:
> - JVM 64KB method-size and constant-pool limits, which force interpreted fallback on deep query plans.
> - Janino compile time per stage.
> - JIT compile work (each stage class has its own bodies).
> This umbrella tracks small, behavior-preserving cleanups across the generated Java to address these issues. Each subtask is independently PR-able; behavior is preserved end-to-end and verified by the relevant operator's existing test suite with {{spark.sql.codegen.wholeStage}} forced both on and off.
> h3. Scope guidance (when is a dead-branch / simplification subtask worth it?)
> Not every statically-dead branch is worth eliminating. We measured the payoff on real generated code (TPC-DS whole-stage codegen): Janino constant-folds {{if (true)}} / {{if (false)}}, so skipping such a branch produces *no bytecode change* and no JIT/runtime benefit -- only smaller source. Janino compile time is ~linear in source (~0.36 ms/KB), and even the most frequent source-only patterns we measured ({{if (true)}} x445, a dead null-write branch x358 -- together only ~0.4% of generated source) saved compile time below the run-to-run noise floor (~0.7%).
> Therefore a subtask that adds branching / complexity to the codegen logic to skip a dead branch is only justified when:
> - *(b) it removes more than source text -- this is the real bar.* For example SPARK-57198: skipping the divide-by-zero guard for a non-zero literal also stops registering the unreachable {{errCtx}} entry in the {{references[]}} / constant pool, which Janino cannot fold away (unlike the {{if (false)}} text itself). Likewise SPARK-57199 moved the {{AGGREGATE_OUT_OF_MEMORY}} string + map constructor out of all 142 generated aggregate classes' constant pools into one compiled method. Keeping a large method under the 64KB / huge-method limit also qualifies.
> - *(a) raw frequency rarely suffices on its own.* As measured above, even patterns occurring 358-445 times stayed below the compile-time noise floor with no bytecode change. Frequency only matters when the dead code is a large fraction of a _single_ method (approaching the 64KB limit), not merely numerous across the corpus.
> Trivial, infrequent (and even frequent-but-source-only) dead-branch removals add codegen-logic complexity for negligible benefit and should be dropped rather than merged.
> h3. Measured cumulative impact (as of master, 2026-07)
> We now measure generated codegen size across all TPC-DS queries with a dedicated, planning-only benchmark added under this umbrella (SPARK-57915): {{org.apache.spark.sql.execution.benchmark.WholeStageCodegenSizeBenchmark}}. It creates the TPC-DS tables empty (SF=100 stats injected so plan shapes match production), plans every query to its {{executedPlan}} with no data or execution, walks the {{WholeStageCodegenExec}} subtrees via {{debug.codegenStringSeq}}, and reports grand totals: generated source size, summed/max compiled method bytecode, generated inner-class count, constant-pool entries, cold Janino compile time, and codegen fallbacks. Run it with {{build/sbt "sql/Test/runMain org.apache.spark.sql.execution.benchmark.WholeStageCodegenSizeBenchmark"}}.
> Comparing {{branch-4.2}} (the 4.2 cut on 2026-05-01, before the bulk of this umbrella's subtasks) against current {{master}} (which carries ~40 SPARK-56908 subtasks merged since) over all 135 measured TPC-DS queries:
> || metric || branch-4.2 || master || delta ||
> | source code size (chars) | 24,190,570 | 21,845,997 | -9.7% |
> | max method bytecode, summed over stages | 951,309 | 841,185 | -11.6% |
> | max method bytecode, single largest method | 6,527 | 4,962 | -24.0% |
> | generated inner classes | 786 | 258 | -67.2% |
> | constant pool, summed over stages | 454,006 | 432,875 | -4.7% |
> | Janino compile time (ms) | 10,784 | 10,362 | -3.9% |
> | codegen fallbacks | 0 | 0 | unchanged |
> The largest wins are in the metrics that actually gate execution and cost: the single largest generated method shrank ~24% (the metric behind the HotSpot 8KB JIT-compilation threshold and the 64KB method limit), and generated inner classes dropped ~67% (fewer classes for Janino to compile, load, and verify, and less metaspace per query per executor). No query regressed on any metric and codegen fallbacks stayed at zero, confirming the changes are behavior-preserving.
> This is the cumulative effect of the whole umbrella's work over that window (dead-check elimination such as SPARK-57198/SPARK-57201, static-helper extraction across many expressions, and the recent fast-hash-map / UnsafeRowWriter / ColumnarToRow / Coalesce reductions), not of any single subtask; each subtask's own before/after numbers are in its linked PR.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org