The focus seemed to have been on improving performance - not a strange goal after the arrival of Windows Vista, which simply didn't perform very well, especially in its early days. Mark Russinovich, Windows NT kernel guru, didn't even try to defend Windows Vista in this regard during his talk.
"One of the things we had decided to do with Windows 7 was, we got a message loud and clear, especially with the trend of netbooks, on top of [other] things," Russinovich said, "People wanted small, efficient, fast, battery-efficient operating systems. So we made a tremendous effort from the start to the finish, from the design to the implementation, measurements, tuning, all the way through the process to make sure that Windows 7 was fast and nimble, even though it provided more features. So this is actually the first release of Windows that has a smaller memory footprint than a previous release of Windows, and that's despite adding all [these] features."
For Windows 7, Microsoft removed several locks that seriously hindered performance - all without breaking a single application. The global dispatcher lock, for instance, is gone completely, and replaced by fine-grained locking which provides 11 types of more specific locks as well as rules on how locks can be obtained so that you no longer run into deadlocks.
The pre-7 dispatcher spent 15% of the CPU time waiting to acquire contended locks. "If you think about it, 15% of the time on a 128-processor system is, more than 15 of these CPUs are pretty much full-time just waiting to acquire contended locks. So we're not getting the most out of this hardware," kernel engineer Arun Kishan explained.
In Windows 7, synchronisation on a global scale is gone, making many operations lock-free. "In its place is a kind of parallel wait path made possible by transactional semantics - a complex way for threads, and the LPs that execute them, to be negotiated symbolically."
Threads don't have to care about this stuff at all, and as such, it's all completely backwards compatible. "Everything works exactly as it did before," Kishan said, "and this is a totally under-the-covers transparent change to applications, except for the fact that things scale better now."
Another notion, hotly contended in the OSNews comments sections as well, is that of "free" memory. As most of you know, Windows tries to page as much stuff you might need into memory as to speed up overall performance of the system. By keeping stuff in memory, the system doesn't have to wait for slow hard drives to feed them said data. Microsoft Distinguished Engineer Landy Wang opened the Task Manager of a regular Windows 7 system with 8GB of RAM, and showed that only 97MB was truly free.
"A lot of people might think, 'Wow, 97 megabytes doesn't seem like a lot of free memory on a machine of that size'," said Wang, "And we like to see this row actually be very small, 97 MB, because we figure that free and zero pages won't generally have a lot of use in this system. What we would rather do, if we have free and zero pages, is populate them with speculated disk or network reads, such that if you need the data later, you won't have to wait for a very slow disk or a very slow network to respond."
Another lock that's gone in Windows 7 is the page dispatcher lock, which has been replaced with a "more complex symbolic system of semantics that lets threads execute in a more parallel, efficient fashion". The page frame number lock has been used for a long time, but with the advent of multicore systems it became clear that it no longer served its function very well - its negative effect popped up in Vista especially.
A page frame number entry indicates the state of a page in memory - is it free, on standby, active, shared, how many processes are talking to it concurrently. All this information is needed to perform state transitions on pages.
"The problem with the PFN lock is that the huge majority of all virtual memory operations were synchronized by a single, system-wide PFN lock," Wang explained, "We had one lock that covered this entire array, and this worked... Okay 20 years ago, where a four-processor system was a big system, 64 MB was almost unheard of in a single machine, and so your PFN database was fairly small - several thousand entries at most - and you didn't have very many cores contending for it."
That has obviously changed in modern times, and in Vista, this architecture simply gave in. The statistic Wang gave during the talk was pretty... Disconcerting. "As you went to 128 processors, SQL Server itself had an 88% PFN lock contention rate. Meaning, nearly one out of every two times it tried to get a lock, it had to spin to wait for it... Which is pretty high, and would only get worse as time went on."
The more fine-grained approach in Windows 7 and Windows Server 2008R2 yields some serious performance improvements: on 32-processor configurations, some operations in SQL and other applications perform 15 times faster than on Vista. And remember, the new fine-grained method has been implemented without any application breakage.
We often snide Microsoft for their focus on backwards compatibility, but that doesn't negate the fact that this is some very impressive work they've done on the kernel. Sure, they won't get the rockstar headlines and train station logos, but it is every bit as impressive - probably a lot more so.