1778423 - Allow realloc() to reuse physical pages

Status: NEW

(Core :: Memory Allocator, enhancement)

Description

[Steve Fink [:sfink] [:s:]]

In bug 1774733, it struck me that when reallocing from a large size to an even larger size, it would save a lot of memory copies if we could reuse the physical pages from the old address range.

So essentially: when reallocing to a somewhat large size, ensure that the larger size is page-aligned. (This is probably already the case.) Then when reallocing to an even larger size, use the equivalent of mremap(..., MREMAP_MAYMOVE) on Linux and update the allocator's accounting to replace the old virtual memory range with the new.

I don't know how hard this would be, or if there's some reason why it's a bad idea, but it would replace some brittle heuristics around optimal resizing and would be faster besides. (I would expect it to completely remove the need for special-casing StringBuilder, for example.)

I thought these sorts of games were easier in Windows, but my first stackoverflow hit seems to say the opposite (iiuc, the solutions there require privileges to pin pages or something.)

Comment 1

[Steve Fink [:sfink] [:s:]]

Another SO thread that I just found claims that jemalloc used to do this, "but it has been removed as of version 4.0 (2015)...It is listed as being problematic for coherency with multi-threaded applications."

Comment 2

[Steve Fink [:sfink] [:s:]]

Jason Evans himself mentions that it triggered deoptimization for mmap requests in the Linux kernel.

Comment 3

[Paul Bone [:pbone]]

(In reply to Steve Fink [:sfink] [:s:] from comment #1)

Another SO thread that I just found claims that jemalloc used to do this, "but it has been removed as of version 4.0 (2015)...It is listed as being problematic for coherency with multi-threaded applications."

I wonder what they mean by "coherency" Maybe pausing all the threads to update page tables? So then I wonder, wouldn't any change to page tables mean pausing all the threads, but that's not true, you could always add new mappings/permissions without that - then perform any pending changes when a thread has a page fault. But unmapping and remapping will want to pause all threads.

Jason's comment makes me think that a determined enough application could keep track of mappings itself and use this to request new mappings at specific addresses that are better choices than Linux's search. We'd also want to test if similar problems exist in MacOS and Windows. If they don't then we could implement it there for most Firefox users.

Comment 4

[Mike Hommey [:glandium]]

One thing that I remember mremap caused problems with is transparent huge pages.