At least for JavaOS and Singularity there were a bunch of problems:
1. They were primarily research OS', Singularity was never even meant to be used at all. Its successor Midori was, but again it never made it outside of MS. JavaOS was sort of targeted at embedded devices but again never had any real usage.
2. Operating systems are ideally very tightly programmed with minimal overhead. Given a choice between elegance and performance, people pick the latter. A slow app can be optimized but if your kernel/drivers are slow then you're often stuck. Whether it's microkernels or operating systems written in managed languages, these better designs sell performance to buy convenience for the implementors, but convenience for users is more important.
3. Midori tried to fix this but ended up spending all its design budget on trying to turn C# into C++ and do fashionable things with concurrency/thread safety, which isn't a compelling basis for an OS. Plan9 at least had features that were interesting for the actual users of the computer, but the Singularity/Midori approach was mostly just a PL nerdout.
Single address space operating systems have some design issues that have never been well addressed, or at least the solutions didn't seem convincing. Unfortunately OS research is stagnant so very little has changed over time.
For example, they need everything to be written in a single (GCd/managed) language, and so existing C/C++ libraries can't be used (without a win3.1 style stability model at least). But the VM itself is written in C/C++, so the first step is to either switch the entire model to AOT compilation (the MS approach) or to write the language VM in the language itself (the Sun approach, which eventually surfaced in real products in the form of GraalVM). The Graal approach seems to solve this problem by being able to run any kind of language on top fot the JVM, even C/C++ code, and it can run it safely/GCd.
Another problem is the question of what exactly replaces a process. Processes in classical operating systems do a lot of different things - sandboxing, data isolation, scheduling, but also things like defining a failure domain. The big advantage of a single address space OS is you can allocate objects and then just pass them around freely without needing all the IPC/serialization/socket bindings/etc stuff that classical kernels require. So the obvious approach is to just not have such a thing as a process - but if you do that, you hit the question of how to manage executing code. What's the equivalent of SIGKILL if you don't have a process? What does a CPU usage graph look like? What happens if a driver does a callback into a piece of code which then deadlocks? This problem combined with the difficulty of finding a one-size-fits-all garbage collection algorithm pushes SAS operating systems towards reintroducing a process-like concept, for instance the Singularity process equivalent was actually way more constraining than a UNIX process, and objects could no longer be passed around freely between subsystems but instead required a convoluted exchange heap + quasi-RPC approach.
1. They were primarily research OS', Singularity was never even meant to be used at all. Its successor Midori was, but again it never made it outside of MS. JavaOS was sort of targeted at embedded devices but again never had any real usage.
2. Operating systems are ideally very tightly programmed with minimal overhead. Given a choice between elegance and performance, people pick the latter. A slow app can be optimized but if your kernel/drivers are slow then you're often stuck. Whether it's microkernels or operating systems written in managed languages, these better designs sell performance to buy convenience for the implementors, but convenience for users is more important.
3. Midori tried to fix this but ended up spending all its design budget on trying to turn C# into C++ and do fashionable things with concurrency/thread safety, which isn't a compelling basis for an OS. Plan9 at least had features that were interesting for the actual users of the computer, but the Singularity/Midori approach was mostly just a PL nerdout.
Single address space operating systems have some design issues that have never been well addressed, or at least the solutions didn't seem convincing. Unfortunately OS research is stagnant so very little has changed over time.
For example, they need everything to be written in a single (GCd/managed) language, and so existing C/C++ libraries can't be used (without a win3.1 style stability model at least). But the VM itself is written in C/C++, so the first step is to either switch the entire model to AOT compilation (the MS approach) or to write the language VM in the language itself (the Sun approach, which eventually surfaced in real products in the form of GraalVM). The Graal approach seems to solve this problem by being able to run any kind of language on top fot the JVM, even C/C++ code, and it can run it safely/GCd.
Another problem is the question of what exactly replaces a process. Processes in classical operating systems do a lot of different things - sandboxing, data isolation, scheduling, but also things like defining a failure domain. The big advantage of a single address space OS is you can allocate objects and then just pass them around freely without needing all the IPC/serialization/socket bindings/etc stuff that classical kernels require. So the obvious approach is to just not have such a thing as a process - but if you do that, you hit the question of how to manage executing code. What's the equivalent of SIGKILL if you don't have a process? What does a CPU usage graph look like? What happens if a driver does a callback into a piece of code which then deadlocks? This problem combined with the difficulty of finding a one-size-fits-all garbage collection algorithm pushes SAS operating systems towards reintroducing a process-like concept, for instance the Singularity process equivalent was actually way more constraining than a UNIX process, and objects could no longer be passed around freely between subsystems but instead required a convoluted exchange heap + quasi-RPC approach.