Hacker News Reader

Comment by zamadatix | Hacker News Reader

> You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3

I had previously seen this described as 0 vs non-zero. Since you have some inside experience :), anything special about 3 instead? What about 2? How would I find these value meanings out on my own (if that's even possible)?

Thanks!

View on HN

It's a combinination of bit flags. The lowest bit controls whether segment heap is on or off. The 2nd lowest bit bit controls some additional optimizations that go along with it, something about multithreading. A value of 3 (both flags set) gives you identical behavior to what specifying <heapType>SegmentHeap</heapType> in your application manifest does.

Using the application manifest approach is the right way to ship software that opts into segment heap. The registry thing is just a convenience for local testing.

How often does software actually ship with the opt in for segment heap turned on though ?

Anyway to globally turn it on when a blacklist or denylist or whatever in case something individual acts up ?

Not nearly often enough, because most veteran Windows deverlopers don't even know what segment heap is, or that they have a choice. VS code, for example, is still on NT Heap. It is heartbreaking how under-utilized and under-publicized segment heap is. Raymond Chen needs to make a public service announcement or something.

For the question of how to do "segment heap on globally, with a list of exceptions that are still on NT Heap", I believe the "Image File Execution Options" regkey takes precedence over the global one. And the IFEO one lets you explicitly opt out. If you read the whitepaper from Mark Yason's 2016 talk at black hat, they explain how to use these registry keys.

Besides better ram utilisation is it offering actual performance improvements (regardless of ram availability) ? Need to read more about this

In terms of speed, anecdotally, it seems like it can go either way. Some programs run faster, some run slower. Usage patterns of malloc/free are so varied that it's probably impossible to optimize for one without hurting others.

Would the (not Framework) .NET apps I work on benefit from this?

Any app using memory allocation functions would benefit from a newer heap implementation independently of a technology it's created with, unless it's actively constrained by compatibility burdens. In case of .NET, the memory layout compatibility is not something you usually care about unless the app loads old 3rd party .DLLs through P/Invoke. So for 99.9% of .NET (not Framework) apps, the segment heap should work just fine.

Much thanks, this is why I come to HN!

Reply on news.ycombinator.com