Skip to content

deps: bump windows-sys from 0.60.2 to 0.61.2 - #6

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/cargo/windows-sys-0.61.2
Open

deps: bump windows-sys from 0.60.2 to 0.61.2#6
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/cargo/windows-sys-0.61.2

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 20, 2026

Copy link
Copy Markdown

Bumps windows-sys from 0.60.2 to 0.61.2.

Release notes

Sourced from windows-sys's releases.

61

Major crate updates:

  • windows 0.59.0
  • windows-core 0.59.0
    • windows-implement 0.59.0
    • windows-interface 0.59.0
  • windows-targets 0.53.0
    • windows_i686_msvc 0.53.0
    • windows_x86_64_msvc 0.53.0
    • windows_aarch64_msvc 0.53.0
    • windows_i686_gnu 0.53.0
    • windows_x86_64_gnu 0.53.0
    • windows_i686_gnullvm 0.53.0
    • windows_x86_64_gnullvm 0.53.0
    • windows_aarch64_gnullvm 0.53.0
  • windows-bindgen 0.59.0
  • windows-registry 0.4.0
  • windows-result 0.3.0
  • windows-strings 0.3.0
  • cppwinrt 0.2.0

Minor crate updates:

  • windows-version 0.1.2

Excluded:

  • windows-sys 0.59.0

Things to keep in mind:

  • The tag/release names no longer map directly to the crate versions, so to find samples for a particular release requires looking at the releases page and finding the release that most recently updated a particular crate.

  • The windows-bindgen crate includes the major code generation overhaul that brings many improvements - be sure to check out the PR description for more information. The resulting code gen depends on the new version of windows-core and its dependencies, unless you include the --sys option. #3359

  • The cppwinrt crate constitutes a major update due to streamlining the error handling. #3415

  • The windows-registry, windows-strings, and windows-result crates are also major version updates since they include small breaking changes.

  • The windows-targets crate finally receives a major version update, the first in over a year. This is due to #3359 and #3342 potentially introducing breaking changes. Although unlikely, these updates introduced sufficient changes that make it hard to ensure that the windows-targets libs don't break existing code. As we're updating windows-targets anyway, I took the liberty to bump the MSRV to 1.60 - to match the latest version of windows-sys - and remove the old but unused doc macro feature. Both remained for compatibility with very old dependents of the windows-targets crate.

  • The windows-version crate receives a minor update to update its dependency on the windows-targets crate.

  • Beyond these specifics, this update is the culmination of around 6 months worth of work on the windows-rs project. The biggest improvements comes from the new code generation engine, but many other improvements are now also available for production. This includes support for many new lints, warnings, and suggestions provided by the Rust toolchain; much smaller code gen thanks to deriving many more traits; more efficient code gen; major improvements to WinRT type system and implementation support; more robust and consistent error handling; stock collection and async support; improved support for class hierarchies; and much more!

In addition to "what's changed" below, check out what's changed for notes for 0.60.0 and 0.59.0 for additional changes that roll up to the crates published as part of this release.

What's Changed

... (truncated)

Commits

@dependabot @github

dependabot Bot commented on behalf of github Aug 20, 2026

Copy link
Copy Markdown
Author

Labels

The following labels could not be found: dependencies, security. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@dependabot
dependabot Bot force-pushed the dependabot/cargo/windows-sys-0.61.2 branch from 69ef3a6 to 7ccb8a9 Compare August 20, 2026 02:38
Ttimmahlax pushed a commit that referenced this pull request Aug 20, 2026
…efuted, nothing shipped)

The +0.47 Ir/op batch_lifo/batch_fifo gap — the one op we lose to mimalloc — is
now localized precisely, and it is NOT algorithmic. Per-function callgrind plus a
direct disassembly of both allocators' free:

  - malloc is at PARITY (ra 15.99/op == mi 15.99/op). The whole gap is in free.
  - free fast path, executed: ours 27 insns, mimalloc 24 (excl. its CET
    endbr64). The +3, instruction for instruction:
      * used-- decrement, +3: mimalloc emits "subw $1, [used]; je" — one
        memory-destination RMW feeding the retire branch (2 insns). We emit
        load / dec / store / test / branch (5). LLVM won't select "dec [mem]; jle"
        because the decremented value must be in memory before the branch (the
        retire tail re-reads used) AND drive the branch.
      * thread compare, +1: mimalloc "cmp %rcx, %fs:0" (TLS self-pointer as a cmp
        operand); we "mov %fs:0,%rcx" then cmp, because thread_id() is an
        inline-asm "mov fs:0" that forces a register.
      * idx * sizeof(Page), -1: we use one imul where mimalloc uses lea+shl — a
        place we are already tighter.

Attempted the obvious fix — split the list-push from the used decrement and
inline the decrement next to the branch, the shape most likely to trigger
"dec [mem]". Result: BYTE-IDENTICAL asm, same mov/dec/mov/test/jle at the same
addresses. Reverted. C's "--page->used <= 0" gets "subw; je" from Clang; the
equivalent Rust does not, and neither fold is reachable without inline asm on the
hottest path in the allocator.

So the batch gap is a Rust-vs-C instruction-selection floor. Closing the last
~0.5% on one synthetic op would take inline asm in free — not worth it against a
path we win on every other op and match on real programs. This commit ships no
logic change: only a NOTE at the decrement so the dead end is not re-explored,
and the full trace in docs/opps.md #6. Verified byte-identical (free disasm
unchanged) and tests green.

Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>
Bumps [windows-sys](https://github.com/microsoft/windows-rs) from 0.60.2 to 0.61.2.
- [Release notes](https://github.com/microsoft/windows-rs/releases)
- [Commits](https://github.com/microsoft/windows-rs/commits)

---
updated-dependencies:
- dependency-name: windows-sys
  dependency-version: 0.61.2
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot force-pushed the dependabot/cargo/windows-sys-0.61.2 branch from 7ccb8a9 to 2613c07 Compare August 20, 2026 22:56
Ttimmahlax pushed a commit that referenced this pull request Aug 22, 2026
`free` is where a real program spends its allocator time — 55% of the
allocator on a steady-state working set — so it is the function worth
counting instruction by instruction. Its fast path is now 21 against
mimalloc's 25, and cfrac's allocator fell 3,994,735,955 -> 3,445,599,360
(-13.7%).

Four of the wins are here:

* `used--` and its retire branch are one memory-destination `sub` whose own
  flags drive the jump, with the cold arm as an `asm!` label block. This is
  the floor `docs/opps.md` #6 measured on four workloads and refuted twice:
  its analysis was right that no arrangement of safe Rust reaches it — LLVM
  will not emit a memory-destination RMW when the value must also drive a
  branch — and its conclusion that the instruction was unreachable was wrong.
  Five instructions became two. #6 is marked CLOSED with the analysis kept.

* The field offset is a `const` operand, so x86 addressing carries the
  displacement instead of a `lea` materialising the address.

* The thread-id read is folded into its own compare (`cmp {tid}, fs:0`);
  `thread_id()` IS the fs base, so the load was redundant. Applied to the
  fast path and to `free_general`.

* Resolving a pointer to its page went from nine instructions to five.
  `Segment::page_off` is a `[u32; 512]` recording, per slice, the byte offset
  from the segment base to the owning page, so the resolution is a scale-4
  load and an `lea` rather than an `imul` by 88, a slot address, a
  `slice_offset` load and a subtraction. It costs 2 KiB in a 32 MiB segment
  header that had ~20 KiB spare, and `page_of` carries a debug assertion that
  the table and `slice_offset` agree on every resolution — the check that
  makes the duplicated state safe to keep.

`free_general` also takes `owner_tid` as an argument rather than re-loading
what the fast path already had in a register.

Also carries the ten earlier campaigns recorded in docs/plans/lets_win.md
(mleak, realloc, aligned, alloc-test, sh8bench, rptest, xmalloc-test,
sh6bench, cfrac, larson-sized), whose changes are interleaved through these
same functions and cannot be separated into per-campaign commits after the
fact.

Gated: clippy clean, 32 suites / 82 tests, tests/abandon_rss 6/6,
bench/datasweep.sh across six allocator arms with 573,640 checks each,
corpus/sweep-all.sh 19/19, and corpus/realworld.sh byte-identical on eight of
nine real programs (the two that differ are a workload that embeds
non-deterministic metadata and a jemalloc-linked redis that fails under
mimalloc identically).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ttimmahlax pushed a commit that referenced this pull request Aug 22, 2026
`docs/plans/lets_win.md` is the working record: where the corpus spends its
time, and then a section per campaign with what landed, what was refuted, and
what the instrument could and could not say. Refutations are kept in full,
because most of them cost more to establish than the wins.

READMEs now carry freshly measured figures, and one column that was missing.
The whole-program ratios understate the allocator by design — allocation is
4.9% of lua, 3.3% of perl, 1.5% of sqlite — so the same runs are also given
decomposed, with the allocator-only ratio (lua 0.66, perl 0.83, sqlite 0.85)
and the floor each row would read if our allocator cost ZERO instructions
(0.93 / 0.96 / 0.98). sqlite sits at 1.00 because of what SQLite is, not what
the allocator does, and the floor column is what makes that legible.

Two corrections to claims that had expired:

* lua is quoted as indicative, not as a verdict. Its hash seed is not
  pinnable from the environment and it moves ~0.26% run to run, which is
  wider than the digit the ratio was being quoted to.

* The per-op table is no longer presented alone. Five of its thirteen
  operations hold one block live at a time, so they measure page
  retire-and-recarve; the working-set ops (`liveset` 0.92, `shbench` 0.91,
  `xthread` 0.83) are the honest number for a program and are given beside
  them.

`docs/opps.md` #6 is marked CLOSED. Its analysis was correct and is kept —
it is the reason the fix has the shape it does — but its conclusion that the
instruction was unreachable no longer holds.

Co-Authored-By: Claude Opus 5 (1M context) <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.

0 participants