Skip to content

Implement Kotzmann VEE'05 connection graph escape analysis for arrays - #6

Draft
tekknolagi with Copilot wants to merge 9 commits into
masterfrom
copilot/implement-escape-analysis-for-arrays
Draft

Implement Kotzmann VEE'05 connection graph escape analysis for arrays#6
tekknolagi with Copilot wants to merge 9 commits into
masterfrom
copilot/implement-escape-analysis-for-arrays

Conversation

Copilot AI commented Feb 4, 2026

Copy link
Copy Markdown

Implements intraprocedural escape analysis following Kotzmann & Mössenböck's VEE'05 approach for array allocations in ZJIT HIR.

Changes

Three-level escape classification

  • NoEscape: Local-only (scalar replacement candidate)
  • ArgEscape: Returned/passed to callees (limited optimization)
  • GlobalEscape: Heap escape via ivars/globals (no optimization)

Connection graph implementation

  • Nodes track allocation sites with escape states
  • Points-to edges model array element relationships (ArrayAref/ArrayAset)
  • Phantom nodes handle unknown references conservatively
  • Fixed-point propagation (typically 2-5 iterations, max 100)

Analysis phases

  1. Build connection graph from array allocations
  2. Add edges: method calls→ArgEscape, ivar stores→GlobalEscape, returns→ArgEscape
  3. Propagate states through points-to relationships
  4. Extract final classifications

Integration with existing infrastructure

  • Leverages LocalArray effect for DCE of NoEscape arrays
  • Compatible with PatchPoint deoptimization
  • Returns HashMap<InsnId, EscapeState> for future optimizations

Example

// Array never leaves method - NoEscape
def local_only
  arr = [1, 2, 3]
  arr.length
end

// Array returned to caller - ArgEscape  
def returns_array
  [1, 2, 3]
end

// Array stored to heap - GlobalEscape
def stores_array
  @arr = [1, 2, 3]
end

Paper: https://www.usenix.org/legacy/events/vee05/full_papers/p111-kotzmann.pdf


💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI and others added 4 commits February 4, 2026 03:18
Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
… improve comments

Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
Copilot AI changed the title [WIP] Add lightweight escape analysis for arrays in ZJIT HIR Implement lightweight escape analysis for arrays in ZJIT HIR Feb 4, 2026
Copilot AI requested a review from tekknolagi February 4, 2026 03:28
Copilot AI and others added 4 commits February 4, 2026 03:50
…n graphs

Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
…eoptimization docs

Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
…improve comments

Co-authored-by: tekknolagi <401167+tekknolagi@users.noreply.github.com>
Copilot AI changed the title Implement lightweight escape analysis for arrays in ZJIT HIR Implement Kotzmann VEE'05 connection graph escape analysis for arrays Feb 4, 2026
tekknolagi pushed a commit that referenced this pull request Jun 25, 2026
…ruby#17479)

When we introduced the inliner we also added repeated passes of the optimization pipeline. The idea being that we want to optimize the results of inlining and, because we only inline one level deep, allow us to perform inlining on the result of the last inlining operation. The optimization loop would exit if we couldn't inline any more. If we could inline more, there's an upper bound that kicks us out of the loop so we don't try to inline the world. However, if we exited the loop by hitting that upper bound, we didn't end up specializing the results of the last inlining pass. This PR rectifies that.

This is immediately visible in the 30k_methods benchmark, where performance roughly doubles.

Before:

```
❯ WARMUP_ITRS=0 MIN_BENCH_ITRS=10 MIN_BENCH_TIME=0 ./run_benchmarks.rb --chruby 'ruby-master --zjit-inline-threshold=30' 30k_methods
Running benchmark "30k_methods" (1/1)
+ /Users/nirvdrum/.rubies/ruby-master/bin/ruby --zjit-inline-threshold\=30 -I harness /Users/nirvdrum/dev/worktrees/ruby-bench/main/benchmarks/30k_methods.rb
ruby 4.1.0dev (2026-06-23T13:29:36Z master 13fe77d) +ZJIT dev +PRISM [arm64-darwin25]
itr:   time
 #1: 2689ms
 #2:   33ms
 #3:   32ms
 #4:   32ms
 #5:   32ms
 #6:   32ms
 #7:   32ms
 Shopify#8:   35ms
 Shopify#9:   33ms
Shopify#10:   33ms
```

After:

```
❯ WARMUP_ITRS=0 MIN_BENCH_ITRS=10 MIN_BENCH_TIME=0 ./run_benchmarks.rb --chruby 'ruby-zjit-opt-last-inline --zjit-inline-threshold=30' 30k_methods
Running benchmark "30k_methods" (1/1)
+ /Users/nirvdrum/.rubies/ruby-zjit-opt-last-inline/bin/ruby --zjit-inline-threshold\=30 -I harness /Users/nirvdrum/dev/worktrees/ruby-bench/main/benchmarks/30k_methods.rb
ruby 4.1.0dev (2026-06-25T13:56:41Z zjit-opt-last-inline 18ce64d) +ZJIT dev +PRISM [arm64-darwin25]
itr:   time
 #1: 2700ms
 #2:   17ms
 #3:   16ms
 #4:   16ms
 #5:   17ms
 #6:   16ms
 #7:   16ms
 Shopify#8:   17ms
 Shopify#9:   16ms
Shopify#10:   16ms
```

Fixes Shopify#998.
tekknolagi pushed a commit that referenced this pull request Sep 9, 2026
ractor_add_port grows a full port table by copying it: st_copy(old_tab), then
st_insert of the new entry, then swapping the copy in under the Ractor lock and
freeing the old table.  Both calls allocate, and an allocation is a safepoint, so
a global GC can run there.  The end of a global GC is where
rb_ractor_reap_dead_ports frees the queues of ports whose Ractor::Port went
unmarked and ST_DELETEs them -- from r->sync.ports, which is still old_tab.  The
copy already taken then carries entries the reap deleted, and swapping it in
republishes queues that have been freed.  The next global GC walks them:

  ERROR: AddressSanitizer: heap-use-after-free
      #0 ractor_queue_mark             ractor_sync.c
      #1 ractor_mark_ports_i           ractor_sync.c
      #3 ractor_sync_mark              ractor_sync.c
      #5 rb_ractor_mark_local_roots    ractor.c
      #6 gc_start_global               gc/default/default.c

Only the owning Ractor inserts into its own table, so a changed entry count means
a reap ran; take the copy again when it did.  The count is checked after each
allocation rather than once at the end: st_copy fills the header before it
allocates the entry storage, so a reap in between leaves the copy counting rows
it does not have, and st_insert must not be handed a table in that state.

The retry is bounded: each failure means the source table lost at least one
entry.

Reproduced with Ractor.select over many Ractors that finish and are absorbed,
with allocation running a global GC underneath (a supervisor loop).  A plain
build crashes only under load; under ASAN, 2 of 3 runs on master and 0 of 5 with
this change.

Co-Authored-By: Claude Opus 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