Visitar URL original
Don't assert that an eqq is followed by another instruction by sferik · Pull Request #9830 · jruby/jruby · GitHub
Skip to content

Don't assert that an eqq is followed by another instruction - #9830

Merged
headius merged 1 commit into
jruby:masterfrom
sferik:jit-eqq-assertion
Oct 20, 2026
Merged

headius merged 1 commit into
jruby:masterfrom
sferik:jit-eqq-assertion

Conversation

@sferik

@sferik sferik commented Oct 19, 2026

Copy link
Copy Markdown
Contributor

Fixes #9829.

With Java assertions on, a block containing a case/in with more than one in clause couldn't be JIT-compiled, because canOmitStoreLoad asserts that an eqq is never the last instruction in its basic block. Inside a block, each in clause's eqq is, since the pattern_end label right after it starts a new basic block. In a method that block gets merged away, which is why only blocks were affected.

The assertion wasn't guarding anything. A null next instruction just means the store and load can't be skipped, and the method already returns false for patterns. So I replaced it with a null check that returns false, and the generated code is the same as before with assertions off.

Since rake runs the tests with -J-ea, this was quietly keeping 13 blocks in ruby/spec and the MRI tests from compiling. The new spec in spec/compiler/general_spec.rb fails in JIT and AOT mode with assertions on before this change, and passes in all four modes after it.

canOmitStoreLoad asserted that the instruction after an eqq is never
null, but it's null whenever the eqq ends its basic block. Inside a
block, each in clause of a case/in does that, because the pattern_end
label after the eqq starts a new basic block. With assertions on, those
blocks failed to compile.

The assertion wasn't protecting anything: a null next instruction just
means the store and load can't be omitted, which is what the method
returns for patterns anyway. Return false instead.

Fixes jruby#9829
@sferik
sferik force-pushed the jit-eqq-assertion branch from 2c39de7 to 8710999 Compare October 19, 2026 23:49

@headius headius left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was likely a valid assertion to make before the advent of patterns, which do some pretty horrendous things under the covers. Hopefully we'll be able to make some improvements to how patterns compile soon.

Trivial fix since the assertion is no longer needed with pattern compilation.

@headius headius added this to the JRuby 10.1.3.0 milestone Oct 20, 2026
@headius
headius merged commit 88117c4 into jruby:master Oct 20, 2026
135 checks passed
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.

With Java assertions on, the JIT can't compile a block containing a case/in with more than one in clause (AssertionError: Somehow EQQ is the last instr in the scope)

2 participants