pj64team / Project64-Legacy

Finishing what we started.
79 stars 7 forks source link

Memory-mapped ROM file #82

Closed parasyte closed 1 year ago

parasyte commented 1 year ago

This saves a lot of heap space by memory mapping the ROM (the memory is file-backed) instead of retaining the entire file contents on the heap.

It has to create a temporary file because it can't map compressed data (from a zip file) and the entire emulator and plugin ecosystem expects the ROM to be stored in little endian. There's also a little hidden hack for Aleck64 games that patches the ROM contents...

As a bonus, the memory mapped file is always read-only. See FILE_MAP_READ documentation in https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-mapviewoffile This allows removing several VirtualProtect() calls.


Here's what the change looks like from the system's virtual memory point of view, using Conker's Bad Fur Day (one of the largest commercial ROMs):

Before:

conker-heap-before

After:

conker-heap-after

The difference is primarily that Heap shrunk and Mapped File grew accordingly.

If you prefer a simpler view of memory, here's what it looks like in task manager (I paused emulation at about the same place in the intro for each screenshot, so CPU is around 0%):

Before:

conker-mem-before

After:

conker-mem-after


See also #41 where memory allocation failures were observed for "large" allocations (64 MB). That PR addressed allocations with the cheat search. This one addresses a similarly large allocation with the ROM file.