Investigate whether the Windows 10 2004 SegmentHeap feature is useful to Firefox
Categories
(Core :: Memory Allocator, enhancement)
Tracking
()
People
(Reporter: RyanVM, Unassigned)
References
()
Details
I came across an article today discussing the new SegmentHeap feature shipping in Windows 10 2004 claiming it reduced Edge memory usage by up to 27%.
I'm not sure if our architecture is amenable to utilizing this new feature or not, but I figured it was at least filing a bug on to investigate!
https://docs.microsoft.com/windows/win32/sbscs/application-manifests#heaptype
|
||
Comment 1•4 years ago
|
||
The article (which Ryan put a link to in the URL section) has some links to Chromium bugs.
The documentation I was looking at was talking about allocations under 16kb, so it sounds like maybe this is some kind of system allocator which we don't use because we have jemalloc? I'm not sure how Chrome does things.
|
||
Comment 2•4 years ago
|
||
This seems to be for HeapAlloc, which we don't use.
Doing a little digging, while Firefox may not explicitly call the HeapAlloc function, the heap documentation implies its a default allocation that happens for each process
https://docs.microsoft.com/en-us/windows/win32/memory/heap-functions
https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests#heaptype
The documentation mentions that the changes impact win32 APIs so I dont know if that impacts Firefox x64
|
||
Comment 6•4 years ago
|
||
(In reply to Mike Hommey [:glandium] from comment #2)
This seems to be for HeapAlloc, which we don't use.
Windows does not provide a way to override the memory allocator process-wide. Sure, our binaries use jemalloc, but any memory allocated by Win32 libraries themselves (or any other dependent DLL, including injected ones) goes through HeapAlloc.
In essence, our Windows processes contain two distinct heap implementations.
Tried running performance tests, what's the best way to see whether there are any advantages? https://treeherder.mozilla.org/#/jobs?repo=try&revision=b15f150b1e5222d2d1ead2999d4f02b7320f11a1
|
||
Comment 8•4 years ago
|
||
I think to compare this, we will need to run multiple triggers of Talos; but we'll need to make sure our Talos machines support it - "This element is supported in Windows 10, version 2004 (build 19041) and later."
Talos machines are probably not running that.
|
Reporter | |
Comment 9•4 years ago
|
||
IIUC, we need to build with the Win10 19041 SDK also.
|
||
Comment 10•4 years ago
|
||
we don't have that, our machines run 1803, there are no plans in the short term to upgrade this- but we have plans by the end of the year.
|
|
||
Comment 11•4 years ago
|
||
AWSY would be the best way to see memory impact, but I'm not sure if we track whatever metric would be affected by this. (Most or all of the metrics we track related to jemalloc's allocations.)
|
|
||
Comment 12•4 years ago
|
||
That said, it would probably affect some number in the memory report, so it wouldn't be impossible to modify it a bit to see if there's a change in whatever metric is relevant.
| Comment hidden (advocacy) |
|
|
||
Comment 14•4 years ago
|
||
|
||
Comment 15•4 years ago
|
||
They will not be using Segment Heap due to the perf regressions.
https://bugs.chromium.org/p/chromium/issues/detail?id=1102281#c29
Instead, they are using something called as "Partition Alloc " : https://chromium-review.googlesource.com/c/chromium/src/+/2543884
Description
•