Управляемые ОС, вероятно, чем-то похожи на микроядра - вы жертвуете производительностью ради безопасности.
Могут быть подобные проблемы, так как это требует разделения кода на 2 части:
- Низкоуровневое ядро, написанное на C / ассемблере
- Ядро высокого уровня, написанное на управляемом языке
В зависимости от стоимости входа / выхода из безопасного языка HL это может вызвать проблемы, аналогичные микроядрам - возможно, немного быстрее (выход из HL быстрее, чем полное переключение контекста, но IIRC, например, JNI, довольно дорогой).
Пользовательскому приложению также, вероятно, потребуются отдельные контексты, поскольку многие приложения написаны на других платформах (например, C, Java или .Net). В тех же случаях приложения могут быть привязаны к процессору (компиляторы, музыкальные конвертеры и т. Д.) И могут требовать даже оптимизации ассемблера для выполнения с достаточной скоростью. Кроме того, защита MMU, реализованная на языке HL, вероятно, будет не такой быстрой, как аппаратная, даже если она будет гораздо более точной.
Кроме того, язык HL не владеет операциями низкого уровня. Хотя программное обеспечение обычно разрабатывается с использованием «хороших» методов кодирования, в драйверах нет необходимости. Я не думаю, что они защитят по крайней мере от некоторых ошибок, поскольку ядрам иногда требуется ручное управление памятью.
Наконец, я не думаю, что такая ОС потребует полной виртуальной машины. Поскольку операционная система не может быть построена на принципах компиляции, один раз запускаемых повсюду, на языках HL (даже с GC & co.) Будет лучшим кандидатом.
Например, вы неожиданно делаете произвольные указатели устаревшими.
ОС изначально низкоуровневая. Вы передаете оборудованию не только «произвольный указатель», но, скорее всего, физический адрес, а не виртуальный. Некоторые DMA могут обрабатывать только первые 16 МБ памяти. Хотя такая ОС может сильно упростить, она не избавится от адресов.
И если хорошо написано, вы избавитесь от тонны устаревшего кода, который есть в большинстве современных ОС.
- Есть много устаревшего оборудования. Гораздо больше, чем в программном обеспечении. Сначала вы запускаете в реальном режиме, затем включаете переход A20 (не спрашивайте) в защищенный режим, затем в длинный режим.
- API / ABI совместимость хорошая. Скажем, они написали такую ОС - что бы вы на ней запустили? Firefox - нет (C и C ++ используют WinAPI). Java - вероятно, его нужно было портировать или иметь некоторые незначительные проблемы через ikvm - если только он не использовал JNI. Я предполагаю, что MSSQL (и, конечно, Oracle, MySQL, Postgresql ...) не написаны на управляемом языке, поэтому он не подходит для сервера.
- Даже ошибка совместимости "хорошая". AFAIK MS тратит много времени, просто проверяя и проверяя, не использует ли какое-либо программное обеспечение API интеллектуальным (читай неправильно) способом. Например, проблема использования указателя после
free
него, когда Windows фактически начала освобождать память.
Я предполагаю, что он получит популярность примерно в то же время, что и микроядра.