Есть ли альтернативы организации виртуальной памяти в операционных системах и железе ?Другими словами почему нету ос с сборкой мусора подобно Jvm?
Какие есть бенчмарки, замеры. какой будет скорость выполнения функции, в реальном режиме. Сколько стоят все операции трансляции.
2 варианта. если первый верен, то ответ получен Ничтожно мала, так как память медленнее скорости процессора, и процесс трансляции, если попадание, как бы уравновешивает там все тайминги Много.
Далее, всегда интересно было, почему нету концепции, как бы глобального сборщика мусора,
Типа рассмотрим высокоуровневую программу с сборкой мусора. И что если просто эту программу масштабировать на ОС. Тогда вместо функций выделения памяти для массивов, будет выделение памяти для программ. А сборка мусора, их освобождение.
Какие есть проблемы у такой концепции, кроме того что допустим нарушается безопасность, и можно получить доступ к другим процессам, хотя так же можно все реализовать с постоянной проверкой за выходы буферов.
Зато сразу вся программа будет в прямой адресацией. любой указатель сразу туда и указывает.
Или сборка мусора много накладывать будет, в то время как в виртуализации памяти сейчас, даже собирать ничего не нужно, само соберётся из-за того что сразу 4гб виртуальной памяти резервирует из которой там 90% процессов только п о страничке и используют. а их освобождение там пройтись по списку used_mem/4096 или того быстрее если там по регионам проходиться.
Или такая концепция не рассматривается из-за легаси побочных технологий?
Выносить сборку мусора в операционку ??
А нужно ?? В разных языках разные сборщики, с отличающимися алгоритмами.
На централизованный сборщик все будут ругатца, что неидеален в ихнем применении....
Я так думаю
Для начала надо попробовать создать средства, способные запускать программы на С, С++, Delphi и т.д. в JVM или .Net Framework.
Если получится без больших накладных расходов, тогда можно думать дальше.
В любом случае придётся переделывать все JVM и прочие VM на новую ОСь. JVM при это похудеет, а вот Ось новая явно потолстеет. И кому такое будет надо - не ясно.
Everything_is_not_so_bad, строго говоря, есть сборщики, которые всячески избегают StW. Но всё равно, мой комментарий больше намекал на то, что сборка мусора - не серебрянная пуля. У неё тоже есть проблемы, иногда очень даже неприятные. И уж точно это не имеет никакого отношения к производительности и эффективному использованию ресурсов.
Сборка мусора это высокоуровневая абстракция над обычным очищением памяти.
Задача ОС связать компоненты пк и дать прикладным программам апи для взаимодействия с ними.
Технически, любая ОС убирает память после завершения процесса. На этом основан
life-cycle PHP странички например. Обработка PHP-responce - это запуск одного
(обычно) Linux процесса.
Всё намного проще. Прикол в том, что для ряда операций вроде видеоускорения и маппинга текстур в видеопамять (браузеры, игры, видеоплееры) нужен прямой доступ к памяти. Мне кажется, по ряду причин такие диапазоны невозможно будет контролировать на предмет невыхода за границы, либо такие проверки слишком замедлят доступ.
Те программы, которые не работают напрямую с железом и не требуют сильно высокого быстродействия - да, почему нет, ваш вариант вполне рабочий. Типа, условная JVM как ОС, а программы - объекты и потоки в ней.
Простой
Простой
Простой
