What happens when you mark a section as DISCARDABLE?

re: What happens when you mark a section as DISCARDABLE?

@BrianEE — Mon, 16 Jul 2012 21:15:58 GMT

"If you only have one small frequently used function and the rarely used functions happen to be in the same page, then what does it matter?"

It's more efficient to group your frequently used functions on the same page, because then those pages will have a high usage and won't ever get pushed to the pagefile. Other, less important functions might suffer pagein hits, but since those are outside of your performance critical paths, you take a slight speed improvement.

This happens because when everything gets paged out (e.g. during a hibernate, during a long pause or context switch or during memory pressure) a fault in one high-usage function automatically pages in other high-usage functions so you don't take the hit twice or three times when calling into them shortly later.

re: What happens when you mark a section as DISCARDABLE?

Gabe — Mon, 16 Jul 2012 15:59:00 GMT

Brian EE: Defense in depth -- by initializing your string to all-0s, you avoid a buffer overflow in the case of certain failures to properly terminate. Maybe you should have a standard initialization byte. You can set it to 0xff for debugging and leave it at 0x00 for all other times.

re: What happens when you mark a section as DISCARDABLE?

Brian_EE — Mon, 16 Jul 2012 15:29:13 GMT

@JamesJohnston: I would fail you for blindly using a zero there instead of some other value. If I initialize a string buffer with all zeros, and am writing some custom string processing function, how do I know my function is properly terminating the string?

I believe that variables should be initialized with data that will maximize chances of discovering bugs and vulnerabilities. Because if you don't discover them, then someone else will.

Personally, if I had to memset a string buffer, the value 0xff would be my choice.

re: What happens when you mark a section as DISCARDABLE?

JamesJohnston — Fri, 13 Jul 2012 16:31:01 GMT

@alegr1: "You can make a file with a list of function names for the linker. See /ORDER option."

From the docs: "Ordering allows you to optimize your program's paging behavior through swap tuning by grouping a function with the functions it calls. You can also group frequently called functions together. These techniques increase the probability that a called function is in memory when it is needed and will not have to be paged from disk."

Well, that's exactly what I'm suggesting then. The next question obviously is going to be how do you systematically keep the list up-to-date from a maintenance standpoint; what procedures should be followed?

@voo: "This seems like something where PGO should be able to help quite easily - whether it does it is another thing."

That's kind of what I was thinking. I've never really looked into PGO very much though so I don't know if it does that. The one time I experimented with it produced a very very modest performance gain, at the cost of greatly increased hassle in the build process. Did not seem worth it.

@Crescens2k: "you can end up with all of the rarely used functions on the same page as a frequently used function"

If you only have one small frequently used function and the rarely used functions happen to be in the same page, then what does it matter? The memory system works in integer multiples of pages, not fractions of a page. Your choices are to put rarely used functions in that space, or null / undefined data.

"increasing the probability that the code you want is in memory already, not allowing you to page out single use functions"

Then logically wouldn't that increase the probability that the code you don't need might be paged out?

@dave: "I fail you on code review if you pull stupid stuff like this"

Unless this is some very hot performance-critical piece of code... why?!? How will zeroing 100 bytes hurt anybody? I do this all the time. It is far easier to rule out undefined behavior at a glance when reading code by just making every variable set to zero, rather than trying to understand the actual workings of the code. Only when proven to be a bottleneck would I actually look at removing it. 99% of code in most products is not going to be a bottleneck. Profilers are your friend - use them!

re: What happens when you mark a section as DISCARDABLE?

asdbsd — Fri, 13 Jul 2012 15:37:23 GMT

@dave: What exactly is "competent" about not knowing where you can safely hand-wave it away, and wasting your brain's resources on thinking about stuff which doesn't matter? That's incompetent in my book. Mindless thinking about everything :) True professional spends all resources, even his own attention and brainpower, wisely.

re: What happens when you mark a section as DISCARDABLE?

Matt — Fri, 13 Jul 2012 14:34:42 GMT

@dave:

Just as a case-in-point, Microsoft have had tons of critical security updates by failing to zero stack buffers in the past, and accidentally having stack-garbage treated as valid (www.iss.net/.../HTML_IE_Uninitialized_Memory_Corruption.htm)

I am not aware of any security vulnerability being caused by excessive initialization of variables. Indeed, if it's obviously superflous, the compiler will remove the memset (since memset is a compiler intrinsic for Visual Studio and why SecureZeroMemory had to be introduced).

In your example, snprintf on its own isn't equivalent because the bytes after the nul-terminated string are still not zero - so if you send buff to someone across a trust-boundary then removing the memset might just have leaked a whole load of data (like ASLR addresses).

re: What happens when you mark a section as DISCARDABLE?

dave — Fri, 13 Jul 2012 14:14:23 GMT

We're getting OT here, but I claim that mindless programming, as exemplified by knee-jerk coding of function calls that you don't need to code, is a major source of software problems. My aim is not to make life miserable for anyone, but to build competent and professional programmers.

re: What happens when you mark a section as DISCARDABLE?

asdbsd — Fri, 13 Jul 2012 13:38:06 GMT

@dave: Mind is a resource. There's only so much of thinking that can be done until you're tired. What's the point of making someone's life miserable and forcing them to think on stuff which doesn't matter?

It's enough that they understand that maybe in some cases zeroing isn't needed, but it hurts nobody. Knowing that, they can decide to just zero out everything and pay their attention to something important instead. That is the reason for those lines of code.

re: What happens when you mark a section as DISCARDABLE?

dave — Fri, 13 Jul 2012 12:56:36 GMT

@Matt

snprintf is perfectly well-behaved. It never writes beyond end of buffer and it always zero-terminates the result (I agree my example code should have checked the return value).

See the C99 specification.

Perhaps you're getting confused with the ill-designed Windows equivalent which does not guarantee termination?

I'm programming in standard C rather than a vendor-specific language, apologies for not saying so.

As far as whether it's a bottleneck: well, probably not, though reflexive zeroing every single buffer will likely be measurable. But really I want programmers to not write lines of code that have no good reason for existing. I want them to think.

re: What happens when you mark a section as DISCARDABLE?

@asdbsd — Fri, 13 Jul 2012 12:37:39 GMT

No. You can't allocate a non-zeroed or mapped page from the kernel. It's true that when you allocate a zeroed page, check that it's full of zeros and come back to it later that you might be seeing DIFFERENT zeroes, but that's not going to affect your app.