Summary
When running Diablo II: Resurrected inside a Parallels VM, the Parallels host process prl_vm_app exhibits sustained heap growth consistent with a runaway allocation loop. The host process grows to ~200-300 GB virtual size with almost all pages swapped out, pushing macOS into high memory pressure, shortly followed by a crash/termination of the entire VM process.
Guest memory usage in Windows Task Manager remains stable (~3 GB idle, ~8 GB under load), suggesting this is not a guest OS/guest application memory leak but a host-side allocation leak in prl_vm_app.
Environment
Parallels build version: 26.2.57373.0
Host OS version: macOS Tahoe 26.0.1 and 26.3
Guest OS version: Windows 11 24H2 and 25H2
Guest application that triggers this leak: Diablo II: Resurrected
Host spec: MacBook Pro M4 Max (16-core, 64GB of memory)
Guest spec: 8 cores, 32GB of memory
Reproduction
Why this is likely a prl_vm_app allocation bug (not a guest OS/application bug)
- The growth is attributed to a host MALLOC ZONE (DefaultMallocZone...), i.e. malloc(3) calls in prl_vm_app itself. This is not the typical accounting shape of "guest RAM backing" (which is usually page-granular and not dominated by billions of tiny malloc allocations).
- The leaked objects are very small (~48 bytes average) and extremely numerous (billions of allocations). That profile is characteristic of host-side object churn.
- Symptom progression aligns with host memory pressure mechanics: as prl_vm_app grows, macOS enters high memory pressure. The guest then exhibits A/V freezes consistent with host-side page-in/page-out latency and resource starvation, followed by VM instability/crash.
Related reports
This appears consistent with previous issues like https://forum.parallels.com/threads/extremely-high-number-on-ram-usage-for-guest-macos-vm.365513 and https://forum.parallels.com/threads/macos-guest-vm-ram-usage.365538
Final thoughts
It should suffice to run D2R for just a few minutes to observe the leak; pinpointing the exact call should be fairly straightforward with debug symbols available.
Happy to provide any extra logs/screenshots if needed, but vmmap is really high signal.
When running Diablo II: Resurrected inside a Parallels VM, the Parallels host process prl_vm_app exhibits sustained heap growth consistent with a runaway allocation loop. The host process grows to ~200-300 GB virtual size with almost all pages swapped out, pushing macOS into high memory pressure, shortly followed by a crash/termination of the entire VM process.
Guest memory usage in Windows Task Manager remains stable (~3 GB idle, ~8 GB under load), suggesting this is not a guest OS/guest application memory leak but a host-side allocation leak in prl_vm_app.
Environment
Parallels build version: 26.2.57373.0
Host OS version: macOS Tahoe 26.0.1 and 26.3
Guest OS version: Windows 11 24H2 and 25H2
Guest application that triggers this leak: Diablo II: Resurrected
Host spec: MacBook Pro M4 Max (16-core, 64GB of memory)
Guest spec: 8 cores, 32GB of memory
Reproduction
- Start the Windows 11 VM in Parallels. Memory profile stays flat.
- Launch Diablo II: Resurrected inside the VM.
- Observe malloc calls steadily increasing at a rate of ~1.1 million/second and process vsize growing at approximately 3.1 GB/minute, suggesting an average allocation size of 48 bytes.
- Initially, resident size grows in lockstep with vsize and gets swapped after a while. In practice, this will show up as memory compression in the host, not as a swap-out to disk.
- Keep the application open for 1h 15m-1h 20m (either in the main menu or inside a game).
- Eventually both game video and audio start stuttering; macOS Activity Monitor shows high memory pressure and what appears to be very high swap activity.
- Finally, the entire prl_vm_app process is killed.
PHP:
VIRTUAL RESIDENT DIRTY SWAPPED ALLOCATION BYTES DIRTY+SWAP REGION
MALLOC ZONE SIZE SIZE SIZE SIZE COUNT ALLOCATED FRAG SIZE % FRAG COUNT
=========== ======= ========= ========= ========= ========= ========= ========= ====== ======
DefaultMallocZone_0x1063c0000 206.4G 85.5M 85.4M 206.1G 4244052755 205.3G 879.8M 1% 54261Why this is likely a prl_vm_app allocation bug (not a guest OS/application bug)
- The growth is attributed to a host MALLOC ZONE (DefaultMallocZone...), i.e. malloc(3) calls in prl_vm_app itself. This is not the typical accounting shape of "guest RAM backing" (which is usually page-granular and not dominated by billions of tiny malloc allocations).
- The leaked objects are very small (~48 bytes average) and extremely numerous (billions of allocations). That profile is characteristic of host-side object churn.
- Symptom progression aligns with host memory pressure mechanics: as prl_vm_app grows, macOS enters high memory pressure. The guest then exhibits A/V freezes consistent with host-side page-in/page-out latency and resource starvation, followed by VM instability/crash.
Related reports
This appears consistent with previous issues like https://forum.parallels.com/threads/extremely-high-number-on-ram-usage-for-guest-macos-vm.365513 and https://forum.parallels.com/threads/macos-guest-vm-ram-usage.365538
Final thoughts
It should suffice to run D2R for just a few minutes to observe the leak; pinpointing the exact call should be fairly straightforward with debug symbols available.
Happy to provide any extra logs/screenshots if needed, but vmmap is really high signal.