Skip to content

Conversation

@tobi
Copy link
Member

@tobi tobi commented Dec 10, 2025

Summary

  • When GuardType operates on a value that is a known frozen object (from a constant), check at compile time if the object's type matches the guard
  • Since frozen objects cannot change their class, the runtime guard becomes unnecessary
  • Eliminates redundant type guards when accessing methods on frozen constant objects, complementing the LoadField folding for ivar reads

Test plan

  • Existing ZJIT tests pass
  • New optimization is covered by the frozen object constant folding tests

🤖 Generated with Claude Code

@tobi tobi force-pushed the zjit-guardtype-frozen-elim branch from 1a03f53 to 7722f20 Compare December 10, 2025 23:20
When GuardType operates on a value that is a known frozen object (from a
constant), we can check at compile time if the object's type matches the
guard. Since frozen objects cannot change their class, the runtime guard
becomes unnecessary.

This optimization eliminates redundant type guards when accessing methods
on frozen constant objects, complementing the LoadField folding for ivar
reads.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@tobi tobi force-pushed the zjit-guardtype-frozen-elim branch from 7722f20 to 59f55f8 Compare December 10, 2025 23:25
self.make_equal_to(insn_id, val);
continue;
}
// If GuardType is on a frozen object, we can check at compile time if the

Choose a reason for hiding this comment

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

I think this should be implied by the is_a in the existing code; we can generally infer types from constant objects (VALUE pointers). Ideally we instead eliminate GuardShape instructions, which we don't have yet

Choose a reason for hiding this comment

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

I think I misspoke when I said we needed to eliminate GuardType, sorry!

Choose a reason for hiding this comment

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

@tekknolagi tekknolagi closed this Dec 16, 2025
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