Skip to content

Document the (uint)i < (uint)length bounds-check idiom and apply it to four sites#2417

Merged
lahma merged 1 commit into
sebastienros:mainfrom
lahma:cleanup/uint-bounds-check
Apr 26, 2026
Merged

Document the (uint)i < (uint)length bounds-check idiom and apply it to four sites#2417
lahma merged 1 commit into
sebastienros:mainfrom
lahma:cleanup/uint-bounds-check

Conversation

@lahma

@lahma lahma commented Apr 26, 2026

Copy link
Copy Markdown
Collaborator

Summary

Two small unrelated improvements bundled together:

  1. CLAUDE.md — adds a Performance Considerations subsection documenting the unsigned-cast bounds-check idiom ((uint) i < (uint) length). The pattern was already used at 15+ sites in this repo (DictionarySlim, StringDictionarySlim, ValueStringBuilder, Arguments, TypeConverter, JsNumber, JintIdentifierExpression, ...) but wasn't explicitly documented as a project convention. The new doc explains how it works (single cmp + jae, JIT can elide the subsequent indexer bounds check), when to apply it, when it adds noise (ordinary for loops where the JIT already elides), and the caveats (works only when length fits in int).

  2. Four candidate sites still using the slower index >= 0 && index < x.Length form, rewritten to (uint) index < (uint) x.Length:

    • Jint/Native/String/StringInlHelper.cs:43stringBuilder.Remove guard
    • Jint/Native/Temporal/TemporalHelpers.cs:4429 — bracket-scan loop while parsing temporal strings
    • Jint/Native/Temporal/PlainYearMonth/PlainYearMonthConstructor.cs:566 — suffix index check
    • Jint/Native/Temporal/ZonedDateTime/ZonedDateTimeConstructor.cs:671 — bracket-scan loop in ZDT parsing

    These are not hot paths (string parsing called at most a few times per parse), so the change is for consistency with the rest of the codebase, not measurable perf. Behavior is identical: both forms accept exactly [0, length).

Validation

  • Jint.Tests (net10.0): 2861 passed, 0 failed.
  • Jint.Tests.Test262 (net10.0): 98567 passed, 506 skipped, 0 failed.

🤖 Generated with Claude Code

…o four sites

Add a CLAUDE.md subsection under "Performance Considerations" explaining
the unsigned-cast bounds check trick: a single unsigned comparison handles
both negative and over-bounds checks, RyuJIT lowers it to one cmp+jae,
and the post-comparison range fact lets the JIT elide the bounds check on
the subsequent indexer access. Includes when-to-use / when-not-to-use
guidance and notes the 15+ existing call sites that already follow this
pattern (DictionarySlim, StringDictionarySlim, ValueStringBuilder,
Arguments, TypeConverter, JsNumber, JintIdentifierExpression, ...).

Apply the same idiom to four spots that still used the slower
`>= 0 && < Length` form:

- StringInlHelper.cs: stringBuilder.Remove guard
- TemporalHelpers.cs: bracket-scan loop in date/time string parsing
- PlainYearMonthConstructor.cs: suffix index check
- ZonedDateTimeConstructor.cs: bracket-scan loop in ZDT parsing

These are not hot paths (string parsing, called at most a few times per
parse), so the change is mostly for consistency with the rest of the
codebase. Behavior is identical — both forms accept exactly [0, Length).

98567 test262 + 2861 Jint.Tests pass; 0 regressions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@lahma
lahma enabled auto-merge (squash) April 26, 2026 02:58
@lahma
lahma merged commit 50cd4a3 into sebastienros:main Apr 26, 2026
4 checks passed
@lahma
lahma deleted the cleanup/uint-bounds-check branch April 26, 2026 03:08
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.

1 participant