On Windows, the allocation granularity can be significantly larger than a page (64K), so with many small objects, just clearing the FreeMem list rapidly leaks quite a bit of virtual memory space (if not rss). Fix that by only removing those parts of the FreeMem blocks that overlap pages for which we are applying memory permissions, rather than dropping the FreeMem blocks entirely.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Jameson Nash points out to me that on windows you're not allowed to pass ranges that straddle allocation domains to it's version of mprotect, so I'll update the code to take that into account.
Updated to take into account that we shouldn't merge things across reservation boundaries.
Instead, have a free block keep a reference to any pending block that may be before it
(in the same allocation) and updating that as we go along.
This sounds great.
I don't think we want to change the operations on MemoryBlock though - I'd rather see SectionMemoryManager create new MemoryBlocks representing the ranges you want to change permissions on.
I added trimMemoryBlock to Memory because it depends on the system Page size, but later realized that Process already exposes that, so I would be happy to just make that a static function in the SectionMemoryManager.
Make trimBlockToPageSize a static in SectionMemoryManager rather than a new
static member of Memory.
Used indices rather than pointers into the array, because those can get
invalidated if you're not careful.