15

Managed OSes like Microsoft Singularity and JNode are quite an interesting concept. Essentially, the OS is bootstrapped with code written in a low-level language (C/C++/Assembly), which essentially implements a virtual machine. The rest of the OS (and all userland apps) run on the virtual machine. There are some great things about this. For example, you suddenly make arbitrary pointers obsolete. And if well written, you get rid of a ton of legacy crud that most modern OSes currently have.

However, as a disadvantage, you're that much farther away from the hardware, and as a developer, you lose the ability to drop down to a lower level of abstraction and get your hands dirty.

What are your opinions on this?

Fishtoaster
  • 25,909
  • 15
  • 111
  • 154
Chinmay Kanchi
  • 6,173
  • 2
  • 39
  • 51
  • I'm afraid to answer since I'm biased towards high level languages since they are the only languages I've used – TheLQ Sep 02 '10 at 23:43
  • 2
    With ever-faster computers, I think this is a big deal. However, if MSFT implements it, it will either be great or suck a lot - there is no in-between. – Job Jan 22 '11 at 23:24
  • Note that the "legacy crud" is what make existing applications run. Do not underestimate the importance of actually having something to use. –  Sep 11 '12 at 06:44

8 Answers8

8

I think that this is another case where "it depends".

If you're writing applications such as web browsers, word processors etc. where lightning fast performance is not necessarily an issue then this approach has it's merits. By using this approach you can offer your customers a safer, more controlled experience. Not only are you limiting the damage that can be done by malware, but you are also running in a more consistent environment.

It's like the difference between console games and PC games. The former know exactly what hardware they need to work with so can make use of that knowledge whereas the latter have to be able to cope with a wider variety of graphics cards, sound cards, hard disk speeds etc.

However, there will be applications (such as games!) that require the low level access and will still need to be run "natively".

Like managed languages you will have to use the appropriate tool for the job.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
  • 3
    I really not agree. There's no reason to have a game running native, and there's no real need to being native to going low level if the operating systems gives you all the managed entry point you need. Of course there's some performance drawback (actually negligible if the entire system is managed) but today we have plenty of processing power and a lot of need of highly-dependable software. – Wizard79 Sep 04 '10 at 12:06
  • @Lorenzo Games already stress computers enough, so the performance hit is important. However, I'm not sure how much the performance impact would be if all the VM does is wrap native calls – TheLQ Sep 04 '10 at 13:25
  • 4
    @TheLQ: the point is that games already don't have to deal with "low level stuff" as there's always some middleware (DirectX, Open GL and so on). Of course they are computationally intensive, but using a middleware is already a performance hit. It would just be a managed (and jitted) middleware. – Wizard79 Sep 04 '10 at 13:40
  • 3
    If the OS takes care of the JITting, you end up with managed code that runs more or less as fast as "native" code. Remember, if you _must_ have assembly-like control over the program, you can always use program directly in byte-code. – Chinmay Kanchi Sep 04 '10 at 13:59
  • @TheLQ, games are almost entirely GPU bound. The performance hit when using a managed abstraction of DirectX, like SlimDX or XNA, is not that high (maybe 5-10% on average?). With better hardware it gets less important. – Matt Olenik Sep 23 '10 at 15:25
  • 3
    Afaik, MS Singularity gets a significant performance *boost* from the fact that it does not need to switch between kernel mode and user mode at all. Forking becomes much cheaper, too. – 9000 Jan 23 '11 at 16:30
3

I think that the benefits of a fully managed OS are huge and that could really be the future, but it will require many years to go.

A good managed operating system will provide you all the managed entry point you need to do every low level thing you need, regardless of being managed: catching interrupts and performing I/O with devices. C# also allows for unsafe code (dealing with pointers) but it will be allowed only in the "device drivers" (which will be just another type of software isolated process).

The benefits in safety, uniformity, portability and especially dependability will certainly exceed any performance drawback. Then a fully managed system is surprisingly fast, as there's no longer need to do context switch.

Wizard79
  • 7,327
  • 2
  • 41
  • 76
  • Are you sure about the context switch not being needed? You still need to run multiple programs at once. – Job Jan 22 '11 at 23:25
  • If both programs and code runs in VM there could be no context switch. However it would require reimplementing MMU in HL language so I really doubt there would be much performance benefit. – Maciej Piechotka Jan 23 '11 at 02:30
3

Generally I think they're a good idea, but since there's not a lot of them around or close to fully baked it very hard to tell how they'd perform in the real world. I wish that MS had updated the Singularity project so that we could see where that was going, but my guess is that some of it is being worked into some version of Windows

Walter
  • 16,158
  • 8
  • 58
  • 95
2

Managed OSes are probably somehow like microkernels - you sacrifice performance in name of safety.

There could be similar problems as it requires splitting code in 2 parts:

  • Low-level kernel written in C/assembler
  • Highier-level kernel written in managed language

Depending on cost on entering/leaving safely HL language it may impose similar problems as microkernels - possibly a bit faster (leaving HL is faster then full context switch but IIRC for example JNI is quite costly).

User application also would probably need separate contexts as many apps are written on other platforms (say C, Java or .Net). In same cases applications may be CPU-bound (compilers, music converters etc.) and need even assembler optimization to perform with sufficient speed. Besides - the MMU protection implemented in HL language probably will not be as fast as hardware one even if it may be much more fine-tuned.

Also HL language does not proficient in the low-level operations. While software is usually designed with "good" coding practice drivers are not necessary so. I don't think they will protect against at least some errors as kernels requires sometimes hand-managing memory.

Finally I don't think that such OS would require full VM. Since the OS cannot be built with principle compile-once-run-everywhere HL languages (even with GC & co.) would make better candidate.

For example, you suddenly make arbitrary pointers obsolete.

OS is inherently low-level. You pass to the hardware not only 'arbitrary pointer' but probably physical address rather then virtual one. Some DMA can handle only first 16MiB of memory. While such OS may simplify a lot it will not get rid of addresses.

And if well written, you get rid of a ton of legacy crud that most modern OSes currently have.

  1. There are a lot of legacy hardware. Much more then in software. You first start in real mode, then enable A20 gate (don't ask) jump into protected mode then into long mode.
  2. API/ABI compatibility is good. Say they have written such OS - what would you run on it? Firefox - nope (C and C++ using WinAPI). Java - probably it needed to be ported or had some minor issues via ikvm - unless it happed to use JNI. I guess MSSQL (and for sure Oracle, MySQL, Postgresql...) is not written in managed language so it would not be fit for server.
  3. Even bug compatibility is "good". AFAIK MS spends a lot of time just testing and checking if some software is not using API in smart (read incorrect) way. Like the problem of using pointer after free it when Windows actually started to free memory.

I guess it will gain popularity around the same time as microkernels.

Maciej Piechotka
  • 2,465
  • 2
  • 18
  • 19
2

Personally, I think the idea of a managed OS is a bit like Communism: good in theory, but impractical to implement.

The problem is that I just don't see any way to bring the managed OS about without completely rewriting the OS from scratch (and I hope someone can prove me wrong on this part). Plus, how do you make decades of unmanaged code fit into a managed OS?

The kernels of the most popular OSes out there are battle-tested and have matured over the course of a couple of decades. You don't simply rewrite them on a whim. Not to mention that history is full of examples of processor designs and kernel architectures that were undeniably better but were never able to convince anyone that they were worth the cost of changing to them.

Lastly, how is a company like Microsoft or Apple going to sell a managed OS to customers? Will the average computer user even care if their OS is managed or unmanaged?

The above noted, I hope that I'm wrong and that managed OSes are going to be a reality. But I'm skeptical. If we do ever see it, it probably won't be for another decade or two.

Jason Baker
  • 9,625
  • 8
  • 44
  • 67
  • 2
    OS kernel is not very important for acceptance. MS devised a totally new, incompatible-to-anything NT kernel, and it was a success. Apple changed its kernel architecture drastically (and its CPU architecture, thrice), and still thrives. The key is compatibility with existing software and ease of porting. Compatibility and/or virtualization layers that allow for smooth transition from old code to new code do not look unreasonably hard in a managed OS. – 9000 Jan 23 '11 at 16:21
2

Managed code is just an extrapolation of what virtual memory protection buys you today, namely the ability of the computer to deny access to ressources.

IBM already does this on their mainframe systems (they just call it something else), so it is in my opinion just a matter of time before this will happen on systems available to the general public.

Would you care if a Google Laptop (which runs Chrome and basically nothing else) runs on managed code or not?

1

However, as a disadvantage, you're that much farther away from the hardware, and as a developer, you lose the ability to drop down to a lower level of abstraction and get your hands dirty.

This is not actually true. In JNode for example, there is an Unsafe class (and others) that allow you to access memory locations and so on. There are also some "magic" classes / methods that are translated into priviledged instructions by the JIT compiler. Access to these classes / methods are (or will be) restricted by the security manager, the JIT compiler and so on. But if you are writing code that executes at the operating system level, these facilities are available to you.

The caveat is (of course) that incorrect use of Unsafe and related classes can lead to operating system crashes immediately, or down the track.

Stephen C
  • 25,180
  • 6
  • 64
  • 87
0

I doubt their usefulness for desktop computers. But time may prove me wrong on this point.

But one interesting potential in my eyes is as a server operating system, more specifically as a guest operating system in a virtualized environment. It never sat right with me to install a full windows server installation in a virtual server environment, knowing how many unnecessary services it runs, including the full GUI.

Now installing something like Singularity on a virtual server for hosting ASP.NET applications, that makes more sense. Assuming that they can keep it a lightweight OS.

Pete
  • 8,916
  • 3
  • 41
  • 53
  • 1
    It is nice to ditch Windows altogether, when you can. – Job Jan 22 '11 at 23:27
  • 1
    The tendency to sandbox browsers and other internet-facing things probably show that a managed, or at least compartmentalized, OS or a desktop is desirable, too. – 9000 Jan 23 '11 at 16:26