Segment heap opt-in/opt-out flags needed

[randomascii]

Item	Value
OS, Version / Build	10.0.19041.0 Microsoft Windows NT 10.0.19041.0
Processor Architecture	AMD64
Processor Type & Model	Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz, 3192 Mhz, 4 Core(s), 8 Logical Processor(s)
Memory	32GB
Storage Type, free / capacity (e.g. C: SSD 128GB / 512GB)	SSD 2TB
Relevant apps installed	Windows Performance Toolkit

Description

Flags to request or refuse the segment heap are needed in order to give applications control over when to use the NT versus segment heaps.

Steps to reproduce

crbug.com/1014701 describes how the NT heap leads to more than 100% memory overhead on some machines in Chrome's browser and network processes when running for a few weeks on many-core machines. Testing with opting-in to the segment heap using the IFEO registry keys showed that on those machines the segment heap dramatically reduced this overhead, saving hundreds of MB. Unfortunately, as shown in crbug.com/1102281 the segment heap increases the CPU cost in renderer processes, adding up to 13% CPU overhead in some scenarios. This means that the very-valuable segment heap is too expensive for us to enable.

Expected behavior

I would like to be able to enable the segment heap for some processes/heaps only.

Actual behavior

I currently have to enable the segment heap for all chrome.exe processes (using the application manifest), meaning that I have to take the good with the bad.
https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests

crrev.com/c/2337959 proves that it would be quite easy for Microsoft to add a function to Windows that would set or clear the "segment-heap-enabled" bit in RtlpHpHeapFeatures in ntdll.dll. Code inspection makes it clear that it would also be easy to add flags to HeapCreate and RtlCreateHeap to force-enable or force-disable the segment heap. These methods would work nicely in conjunction with the manifest, which by itself is too inflexible to be a complete solution.

That is, we really need these two HeapCreate flags:

HEAP_ENABLE_SEGMENT_HEAP - create a segment heap instead of an NT heap
HEAP_DISABLE_SEGMENT_HEAP - create an NT heap instead of a segment heap, even if the segment heap was requested in the application manifest

Alternately, if we had some way to get the address of RtlpHpHeapFeatures then we could clear that flag in our renderer processes after creating them but before starting. This would ensure that even the process heap would be of the desired type.

These flags would be useful for all Chromium-based browsers.

[bitcrazed]

Hey @randomascii - thanks for filing. I've discussed your issue report above with the team.

For those following along, first a little background and context re. Segment Heap: Segment Heap is a new heap implementation, not just a spruced up LFH. It was initially focused on addressing architectural problems in the older heap which prevented memory from being released in a number of important code-paths. Later improvements to the Segment Heap resulted in significant memory footprint reductions, at the cost of some CPU overhead required to more effectively manage the heap.

Work continues on Segment Heap to improve perf, with the goal of (at least) achieving net-perf-equivalence whilst delivering significant memory-footprint reductions for most apps.

The goal is to seamlessly and smoothly migrate apps and tools over to use the new Segment Heap, and to continue to make improvements to the new Segment Heap over time. To accomplish this, we want to avoid having apps and tools depend upon the Segment Heap’s internal workings, otherwise we’ll be unable to make changes without breaking things in the future. This is one of the reasons why we’re not publicly documenting the Segment Heap’s internal workings right now.

Regarding the issue described above, the approach of dynamically selecting which heap to use presupposes performance and memory-footprint characteristics that may well not hold true in the future. As such, it is unwise to opt some portions of the app into using Segment Heap for its memory-footprint improvements, while opting other portions of the app into the legacy Heap for perf reasons.

Note: The team have made some improvements to Segment Heap to address previously reported performance concerns. Those improvements should appear soon in a Win10 Insiders Dev Ring release. They will also be backported to and shipped via the normal servicing channels to existing shipping OS' in the future.

The Segment Heap team encourage you to file Segment Heap issues in this repo, so that the team can learn about the issues you’re finding and can work with (all of) you to deliver solid, supportable fixes and improvements to address your concerns.

[bitcrazed]

Hey @randomascii and others - thanks for filing this issue. Closing since there's no further active work required for this issue.