Software 44833 Published by

FEX 2609, the September 2026 release of the open-source x86-to-ARM64 emulator by FEX-Emu, introduces a major disk caching subsystem that stores JIT-generated code to disk to eliminate stutter during initial game and application launches. The update also delivers measurable speedups, including a 2x performance uplift on specific SIMD code paths and reduced lock contention, while hardening Wine compatibility by removing risky Unixlib fallbacks and improving exception handling for WoW64 builds. Developers shipped roughly 257 commits from eleven contributors in a single month, reflecting an accelerated pace driven by the complexity of the new caching architecture and stability improvements. Users can enable the experimental disk cache by setting the FEX_DISKCACHE=1 environment variable, though the team warns that applications using self-modifying code may cause the cache to grow unbounded until eviction logic is implemented.



FEX 2609 Ships with Disk Cache and Record Commit Load

FEX 2609 has officially landed, and it represents a notably heavier development month than usual for the open-source x86 emulator project. Maintainer Ryan Houdek tagged the release today.

If you're running Windows applications or games on ARM64 Linux, this is the build you'll want to keep an eye on. FEX continues to chip away at the performance gap by acting as a fast binary recompiler, letting x86 code run natively on ARM64 hardware.

Fexemu

Disk Cache and Performance

The headline feature for FEX 2609 is JIT code disk caching. You can enable it by setting the FEX_DISKCACHE=1 environment variable or adding "DiskCache": "1" to your JSON configuration. When active, FEX writes generated code to a custom FOZ format database on disk.

Next time you launch a game or application, FEX checks the cache first. If the code is already there, it skips the JIT compilation entirely. This targets that notorious "JIT stutter" where games hitch the first time they encounter a new code path.

Keep in mind that the cache lives in your ~/.cache/fex-emu/ directory for Linux interpreters or %APPDATA% for Wine setups. The feature is marked experimental, and the team is upfront about the limitations. Applications that use self-modifying code can cause the cache to bloat indefinitely, since there are no size limits or stale-entry eviction built in yet.

The implementation itself is fairly complex, accounting for roughly 18 commits in this release. It includes writer thread optimization with low-priority scheduling and shared memory statistics tracking.

On the performance front, the team squeezed out a measurable uplift. A PMULHRSW instruction optimization reportedly delivers a 2x performance boost on certain code paths. If your benchmark scores or in-game framerate feel sluggish, this might be the fix you need. Reduced JIT lock contention also helps when multiple threads are compiling code simultaneously.

Wine Hardening and Dev Load

The Unixlib fallbacks that FEX used to maintain have been cut. Previously, these fallbacks would accidentally execute Windows syscalls if you swapped out JIT components, which created correctness and security headaches. Removing them cleans up the Wine integration significantly.

Wine users will also notice improved NtRaiseException handling and INT 3 interrupt support. The Windows CRT now has basic printf/puts stubs, and the team fixed a syscall regression that plagued previous builds.

FEX 2609 brings roughly 257 commits from 11 contributors in a single month. That's a considerable jump from the typical 100 to 150 commits seen in prior months. The team's blog admits that time "kept moving faster than expected," which is a polite way of saying they had a lot of work to finish.

It's a rather aggressive commit count for a single month, but the disk cache subsystem required a lot of architectural groundwork. The removal of hacky fallbacks and the hardening of syscall handling show that the project is maturing past its early experimental phase.

Head here to grab the latest FEX 2609 release. The project requires ARMv8.0+ hardware and an x86-64 RootFS for the guest environment.