Здравствуйте, _Oswald_, Вы писали:
_O_>Не совсем так.Тут есть их интервью _O_>Это ведь не первая VM OS. Та же Singularity, например.
Интересный текст, спасибо.
Скажите мне темному, правильно ли я понял структуру:
— boot-загрузчик — native
— обработчик прерываний железа — native
— менеджер памяти (кучи) — native
— менеждер драйверов — native
— драйвера железа — safe
— файловая система — safe (ибо драйвер)
Если я не ошибся, то как тогда обработчик прерывания обращений к виртуальной памяти будет подгружать нужную память с диска? Ведь он native, а драйвер файловой системы — safe?
A>Если я не ошибся, то как тогда обработчик прерывания обращений к виртуальной памяти будет подгружать нужную память с диска? Ведь он native, а драйвер файловой системы — safe?
А им ничто не мешает. Всё, что managed — это те же бинарники, только с GC. Вызываться могут через те же прерывания или таблицу модулей.
Здравствуйте, matumba, Вы писали:
A>>Если я не ошибся, то как тогда обработчик прерывания обращений к виртуальной памяти будет подгружать нужную память с диска? Ведь он native, а драйвер файловой системы — safe?
M>А им ничто не мешает. Всё, что managed — это те же бинарники, только с GC. Вызываться могут через те же прерывания или таблицу модулей.
Я правильно понял, что managed код будет вызываться из unmanaged?
Если да, то что делать в такой схеме:
1. VM обратилась к виртуальной памяти
2. память выгружена в своп, произошло исключение
3. это исключение поймал unmanaged код (он обработчик этих исключений)
4. код вызвал managed драйвер жесткого диска (или файловой системы — не прнципиально)
5. во время работы managed кода потребовалась память и — goto п.2.
Как отнесется процесор к ситуации если внутри обработчика исключения произойдет повторное исключение? И правильно ли возникновение таких ситуаций?
Здравствуйте, Andrbig, Вы писали:
A>Я правильно понял, что managed код будет вызываться из unmanaged?
И?
1. UNMANAGED обратилась к виртуальной памяти
2. память выгружена в своп, произошло исключение
3. это исключение поймал unmanaged код (он обработчик этих исключений)
4. код вызвал UNMANAGED драйвер жесткого диска (или файловой системы — не прнципиально)
5. во время работы UNMANAGED кода потребовалась память и — goto п.2.
Всеголишь нужно не выгружать в своп память важных процессов.
A>Как отнесется процесор к ситуации если внутри обработчика исключения произойдет повторное исключение? И правильно ли возникновение таких ситуаций?
Чего?
Вобще говоря все что нужно это чтобы на уровне виртуальной машины поддерживались процессы в которые нельзя подгружать код после их запуска.
Далие просто компилируем эти процессы и нам уже все равно менеджед они или не очень.
Также никто не мешает вкомпиливать в разные процессы разные менеджеры памяти.
Скажем в процесс который рулит виртуальной памятью компилим вобще без ГЦ. Пусть region inference работает. И заставить его жить в фиксированном объеме памяти. Да придется код писать болие акуратно но для пары процессов на всью ось можно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>1. UNMANAGED обратилась к виртуальной памяти WH>2. память выгружена в своп, произошло исключение WH>3. это исключение поймал unmanaged код (он обработчик этих исключений) WH>4. код вызвал UNMANAGED драйвер жесткого диска (или файловой системы — не прнципиально) WH>5. во время работы UNMANAGED кода потребовалась память и — goto п.2.
Не могу согласиться с выделенным. Вот комментарии авторов здесь
10. What is the design of your driver model? The holly grail of every driver developer is the write once run everywhere. What steps are taken in order to make this a reality in your design?
Scott Balmos : Unless otherwise deemed to be necessary down the road, all drivers would be written and compiled to safe CIL bytecode form — inherently platform independent. In reality, the vast majority of drivers are platform independent, focusing only on their own hardware, of which most communication is through some form of memory-mapped I/O. The base driver classes would handle all unsafe code, which include providing the necessary read and write methods to a given memory address. A driver manager would handle device ID to driver mapping, as well as driver object instantiation.
Так что драйвера managed, причем все.
WH>Также никто не мешает вкомпиливать в разные процессы разные менеджеры памяти. WH>Скажем в процесс который рулит виртуальной памятью компилим вобще без ГЦ. Пусть region inference работает. И заставить его жить в фиксированном объеме памяти. Да придется код писать болие акуратно но для пары процессов на всью ось можно.
Криво, но похоже что да, кроме как фиксить кусок памяти, никак не получися.
Здравствуйте, WolfHound, Вы писали:
WH>4. код вызвал UNMANAGED драйвер жесткого диска (или файловой системы — не прнципиально) WH>5. во время работы UNMANAGED кода потребовалась память и — goto п.2.
Обычно просто делают так, чтобы п.5 был невозможен. Например, с помощью OOM-киллера в Линуксе.
WH>Также никто не мешает вкомпиливать в разные процессы разные менеджеры памяти. WH>Скажем в процесс который рулит виртуальной памятью компилим вобще без ГЦ. Пусть region inference работает. И заставить его жить в фиксированном объеме памяти. Да придется код писать болие акуратно но для пары процессов на всью ось можно.
Ага. Ты знаешь, что с region inference можно получить нехилые утечки? Проще уж писать на нормальном unmanaged-языке и не мучаться.
Я смотрел Singularity — не впечатлило. Набор критичного managed-кода слишком большой.
Здравствуйте, Andrbig, Вы писали:
A>Не могу согласиться с выделенным.
Это я к тому что все твои притензии точно также относятся и к UNMANAGED... так что...
A>Так что драйвера managed, причем все.
И?
A>Криво, но похоже что да, кроме как фиксить кусок памяти, никак не получися.
1)Фиксить придется только один два процесса.
Рутовый процесс. В его контексте работает все.
Страничный менеджер.
Ну может еще шедуллеры... по одному на ядро.
2)Еще нескольким не давать выгружаться в своп и вобщем все.
Ситуация когда нет страниц которые нельзя отобрать у других процессов практически не реальна.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Обычно просто делают так, чтобы п.5 был невозможен. Например, с помощью OOM-киллера в Линуксе.
Это уже детали.
Я к тому что не корректно говорить что это проблемы managed кода. Это проблемы вобще любого кода в данной части системы.
C>Ага. Ты знаешь, что с region inference можно получить нехилые утечки?
Если писать правильно то не получишь.
Тем болие что такие вещи как страничный менеджер нужно писать ну очень акуратно и вдумчиво.
C>Проще уж писать на нормальном unmanaged-языке и не мучаться.
И трястись над указателями и проездами по памяти?
Спасибо не надо.
C>Я смотрел Singularity — не впечатлило. Набор критичного managed-кода слишком большой.
А кто сказал что сингулярити сделана правильно?
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Лично я сильно глубоко в космос вдаваться не буду — мне интересны решения для конечных пользователей, а такой платформенный хардкор от них слишком далек. Но искренне желаю парням удачи — по крайней мере, опенсорсная природа проекта даст большому количеству народа доступ к тем граблям, на которые они еще наступят. Эти грабли, возможно, лягут в основу того софта, который мы будем видеть повсеместно в двадцатые годы.
Ну вообще есть хороший шанс, что подобные проекты скоро начнут плодиться как грибы.
