Skip to content

Add ast_churn: port of Go's garbage benchmark - #103

Open
gbaraldi wants to merge 1 commit into
mainfrom
add-ast-churn-benchmark
Open

Add ast_churn: port of Go's garbage benchmark#103
gbaraldi wants to merge 1 commit into
mainfrom
add-ast-churn-benchmark

Conversation

@gbaraldi

@gbaraldi gbaraldi commented Aug 4, 2026

Copy link
Copy Markdown
Member

Port of Go's garbage benchmark (golang/benchmarks garbage/garbage.go), the GC-heavy workload used to motivate the Green Tea collector.

2 * nthreads tasks repeatedly parse ~10 files of Base source with Meta.parseall, keeping a rotating window of 64 parsed ASTs alive; only the first half of the window is overwritten, so the second half behaves as an old generation (as in the Go original).

Why it earns a slot in the suite: an AST is a deep pointer graph of many different small types (Expr, Symbol, LineNumberNode, Vector{Any}, literals), so the mark phase cannot assume neighbouring objects share a layout. That heterogeneous-heap profile is what package loading and tooling workloads look like, and no current benchmark has it — the binary-tree and array benches are homogeneous. While characterizing mark-phase experiments on julia master we found this workload consistently responds differently from every synthetic benchmark in the suite, which is exactly why it's worth tracking.

Measured on Julia 1.12.6, 4 threads (Zen 4): ~9 s, ~6 GB allocated, ~22% of time in GC.

Disclosure: this PR was written with the assistance of generative AI (Claude).

🤖 Generated with Claude Code

Repeatedly parse Julia source from Base with Meta.parseall on 2*nthreads
concurrent tasks, keeping a rotating window of parsed ASTs alive so half the
window behaves as an old generation. This is a port of Go's `garbage`
benchmark (golang/benchmarks/garbage), the workload used to motivate the
Green Tea collector.

Unlike the binary-tree benchmarks, an AST is a graph of many different small
types (Expr, Symbol, LineNumberNode, Vector{Any}), so the mark phase cannot
assume neighbouring objects share a layout - a heterogeneous-heap stress test
the suite currently lacks. On a Zen 4 machine with 4 threads it runs ~9s with
~22% of time in GC.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants