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.
- 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.
- 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.
- 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.