Christopher Brumme - Is a managed kernel possible?

Woot.. AND after we have this wonderful kernel, why not store everything in XML. [/Sarcasm]

You guys seriously live in your own little magical world where CPU is infinite all you do it comes up with thousands of new ways to make our computers EVEN slower. There is a need to find a good balance between speed and security, building the kernel in this way is not the answer. It is like the one step forward two steps back approach.

Seriously, lately it seems like increases in CPU and RAM have only been used to let software get fat and programmers lazy. The XML parser is example 1 in that case.

First I think they will be going in the other direction, allowing drivers to run in user mode.  That is what they were saying at WinHEC anyhow.  That in the Longhorn time frame we would see user mode driver support in the WDF.

That sounds like what this guy is working on.

"Galen Hunt
Researcher

I am a Researcher leading a project to build a prototype research OS kernel, called Singularity, on managed code. We are using Singularity to exploring issues of system reliability. In this context, I loosely define reliabity as, "the system never does anything unexpected or unanticipated by the its designers, developers, administrators, or users."

Sounds very interesting, but I imagine it'll be several years before this gets anywhere near a commercial product.

In my opinion,

Windows' kernel should definately become .NET-based in the future, when hardware will be better. Old Win32 kernel compatibility should be provided as an emulated environment, just like is DOS today in Win32. Getting the kernel to .NET is a needed step forward, and even if the computers will run it slower, it will be extremely benefic especially for developers (including drivers developers or so, which today have many headaches with developing on the not-managed core of Windows). Personally, I always exchange speed on elegance, therefore, I vote for it: bring .NET to the Windows core as soon as technically possible and economically possible...

Beside those thoughts, I think that Micrsoft should talk with Intel, AMD or so, to create .NET-supporting processors, processors which hopefully will be able to run MSIL directly, therefore, very fast! What do you think about this hardware change to come together with the new .NET Windows core?

Has anyone manufactured (or is anyone planning to) a cpu that can execute IL directly? surely there's no speed compromise on a CPU that could do that?

damphlett wrote:

Has anyone manufactured (or is anyone planning to) a cpu that can execute IL directly? surely there's no speed compromise on a CPU that could do that?

Transmeta has already demonstrated a processor that can execute Java bytecode.

I find this concept very interesting. I've thought about it, but didn't give it a seroius thinking through. If Windows' Kernel DID become .NET based, I'd like it if some applications were open source (like Paint, Word Pad, Calculator, etc) so people could build on those and make Windows even better by turning MS Paint into something that might do some of the stuff Photoshop does or Fireworks. We could turn those basic apps into something really special (ahem, fix the JPEG compression, make it so you can select created objects and move them around at anytime, etc).

A .NET kernel... Sounds interesting!

Manip wrote:

This is insanity. I mean if you were serious about sacrificing speed for security then why not look at a Micro-Kernel? I mean the big draw-back of that is you have a speed drop (nowhere near how much this would) but is more secure because the modules can't damage the core kernel.

It would also load super-fast and be super-stable!

How will a micro-kernal load any faster?  If I move a bunch of code that is now in kernal space into user space, how does that decrease the total amount of code I have to execute in order to startup?

As for the big push to move everything into user space, remember that NT originally started out that way (back in the NT 3.51 days).  When they made the switch to 4.0, Microsoft made the decision to move the GDI portion into the kernal in order to speed things up significantly (this was the same time they made the switch to the win9X interface, which required a heck of a lot of horse power in those days).  Ever since, the trend has been to continue to move into the kernal.  With Windows 2003 for example, IIS came with a kernal mode driver for processing http requests. Again, there is the tradeoff between performance and the beautiful abstraction that is user space. 

I for one think that the OS is such a core component that sqeezing every ounce of performance out of it should be a must.  After all, anone who has profiled their own code knows that for the majority of applications, only a small percentage of time is ever spent running application code.  System code will typically take up at least an order of magnitude more processing time.

The core kernel is dramatically smaller. So the core kernel will load faster, could also be better optimized for a speedy load (appearance of speed to the user). Also, it is easier to pick and choose what is in the kernel and thus less should be loaded at all.

Wow, it's been a while since I heard anyone promoting microkernels. Like '90s style

The microkernel dream doesn't really pan out in reality. Apart from the performance issues Charles mentions, it is quite feasible for a device driver to crash the machine whether it's running in kernel or user mode because it by definition needs to have access to the hardware. OK, you could make the driver go through kernel to sanity-check all the IO operations, but that would make it yet slower still.


As for other people's comments about hardware to directly execute bytecode... Sun tried this with Java and it's not really practical. The stack based architecture of the JVM and CIL isn't designed for hardware execution. That's not to say you can't design hardware that would execute the code, but rather that you would have trouble doing all the speculative and out-of-order execution that modern CPUs do. You could of course translate the CIL into another more conventional register-based instruction set behind the scenes and then take advantage of the huge amount of existing knowlege about how to execute that quickly, and this is what Trasmeta do. If you go this route though it's difficult to see what benefit you then have over a regular JIT like the CLR.

Manip wrote:

The core kernel is dramatically smaller. So the core kernel will load faster, could also be better optimized for a speedy load (appearance of speed to the user). Also, it is easier to pick and choose what is in the kernel and thus less should be loaded at all.

Yes, the core kernal would load faster.  But overall system startup time would not change very much if at all.  I have to load things like the graphics system at one time or another.  If it is in the kernal or in user space, I have to execute roughly (order of magnitude here) the same number of instructions.  Again, how is this going to change my overall startup and run time performance?  Who cares when the core kernal is booted up?  I care when I can do actual work:)

I definetly think that Kernel should be managed in the future (probably in 64 bit or 128 bit era).

If Microsoft is thinking that .Net is the future, than I believe that, when the time comes, the whole Operating System will be written with .Net managed code, but I don't know, if the operating system will still be called "Windows" at that time.

Time's going very fast (and faster), we gotta catch it.

How'bout this: Managed Intel CPUs

Mert