Comments 62
все же надо попробовать отказаться от сборки мусора, имхо это более перспективно.
Разовью свой тезис из прошлого комментария. На мой взгляд, идея виртуальной байт-код машины со сборкой мусора морально устарела после появления Rust. Этот язык демонстрирует альтернативный подход к управлению памятью и синхронизации, основанный на проверках во время компиляции.
Идеальная система мне видится вот какой. Она чуть менее чем полностью написана на Rust. Исполняемые модули снабжаются манифестом с цифровой подписью. Манифест, в том числе, содержит информацию о том, использовалось ли в коде ключевое слово «unsafe». Модули простых смертных, собранные из кода, содержащего это ключевое слово, не могут быть запущенны. Таким образом нет нужды в жирных абстракциях со сборкой мусора.
Если надумаете писать Фантом 2.0 без виртуальной машины, готов безвозмездно принимать участие как в проектировании, так и в реализации.
Идеальная система мне видится вот какой. Она чуть менее чем полностью написана на Rust. Исполняемые модули снабжаются манифестом с цифровой подписью. Манифест, в том числе, содержит информацию о том, использовалось ли в коде ключевое слово «unsafe». Модули простых смертных, собранные из кода, содержащего это ключевое слово, не могут быть запущенны. Таким образом нет нужды в жирных абстракциях со сборкой мусора.
Если надумаете писать Фантом 2.0 без виртуальной машины, готов безвозмездно принимать участие как в проектировании, так и в реализации.
Зачем ждать? Сделайте rust рантайм для фантома, ничто не мешает иметь две модели.
Ну и про виртуальную машину — большинство критиков виртуальной машины смотрят на неё как на среду исполнения. Виртуальная машина — это среда исполнения только для кода, который исполняется один раз. Смотрите на неё как на промежуток между двумя фазами компиляции, и жизнь заиграет новыми красками.
Жизнь не заиграет красками, потому что мне навязывается объектно-ориентированная модель, которая не всегда уместна, а также сборка мусора, которая подходит далеко не ко всем приложениям.
Ну так-то весь смысл ОС Фантом в обеспечении жизненного цикла объектов, более того как только в программе появляется код ожидающий от входящих данных какой-то структуры, так сразу начинается «объектно-ориентированная модель»
Сама по себе ОО модель (во всяком случае, в Фантоме) не так уж рестриктивна. Во всяком случае, функциональное программирование вполне вмещается, и точно будет явно поддержано (кое-где уже поддержано). А где ещё жмёт? Вся объектность сводится к тому, что есть пойнтер на класс и неявно передаваемый this — это само по себе бесит :), или реально как-то мешает?
В Расте уже можно сделать реализацию двусвязного списка не используя unsafe?
Не имеет значения. Unsafe-модули должны обладать доверенным сертификатом для того, чтобы быть быть запущенными. Так что или библиотека от доверенного источника или наличие собственных прав на unsafe.
т.е. есть выбор.
1. Система, в которой физически нельзя сделать unsafe, потому что такой возможности нет и он не нужен.
2. Система, в которой я должен доверять коду, если он использует unsafe (а он вынужден использовать — одина из базовых структур требует).
Что-ж выбрать-та. Прям не знаю.
1. Система, в которой физически нельзя сделать unsafe, потому что такой возможности нет и он не нужен.
2. Система, в которой я должен доверять коду, если он использует unsafe (а он вынужден использовать — одина из базовых структур требует).
Что-ж выбрать-та. Прям не знаю.
Раст — очень симпатичный язык, но метод закапывания GC под ковёр выглядит как-то по-детски. Правда. Это вылезет. Правда, тем не менее, я бы переписал ядро фантома на Rust-е, если бы он был так же широко поддержан. Это — очень неплохой ход вперёд для системного программирования. Для прикладного — это шаг назад.
Мне кажется, что стоило бы пересмотреть список требований к ОС, найти то, чего реально не хватает современным системам.
Я, к примеру, всегда был и являюсь приверженцем персистентости, но в последнее время начинаю всё чаще сомневаться в её востребованности: в реальном мире долгоживущие программы будут протекать и сбоить (следовательно, и хранимые внутри их данные будут теряться).
С другой стороны очевидна необходимость поддержки полностью прозрачной распределённости (современные системы предлагают лишь костыли для решения проблемы удалённого доступа к ресурсам). С другой стороны, распределённые системы уже давно существуют, и тем не менее остаются невостребованными. И это тоже повод для размышления.
Короче, мне кажется, требуется очень ясное и прагматичное представление того, что нужно, а что будет лишним.
Я, к примеру, всегда был и являюсь приверженцем персистентости, но в последнее время начинаю всё чаще сомневаться в её востребованности: в реальном мире долгоживущие программы будут протекать и сбоить (следовательно, и хранимые внутри их данные будут теряться).
С другой стороны очевидна необходимость поддержки полностью прозрачной распределённости (современные системы предлагают лишь костыли для решения проблемы удалённого доступа к ресурсам). С другой стороны, распределённые системы уже давно существуют, и тем не менее остаются невостребованными. И это тоже повод для размышления.
Короче, мне кажется, требуется очень ясное и прагматичное представление того, что нужно, а что будет лишним.
А почему, собственно, нельзя? Weak же есть.
Прям с самого начала файла:
Ну т.е. unsafe обёрнуто в обёртку.
Еще раз, разница между «есть код кторому нужно верить» и «код не может сделать ничего противоестественного» — очень ощутимая.
pub fn new() -> Weak<T> {
unsafe {
Weak {
Ну т.е. unsafe обёрнуто в обёртку.
Еще раз, разница между «есть код кторому нужно верить» и «код не может сделать ничего противоестественного» — очень ощутимая.
Ну, так можно и дойти до недоверия ядру. Но да, аргумент в принципе засчитан.
Хотя с такой позиции сомнительно, что можно вообще гарантировать безопасность доступа к памяти в общем случае. Для VM встаёт вопрос доверия к тому же GC — чем он лучше stdlib в плане доверия? stdlib rust можно включить прямо в дистр(сделав предварительно нормальную динамическую линковку).
Хотя с такой позиции сомнительно, что можно вообще гарантировать безопасность доступа к памяти в общем случае. Для VM встаёт вопрос доверия к тому же GC — чем он лучше stdlib в плане доверия? stdlib rust можно включить прямо в дистр(сделав предварительно нормальную динамическую линковку).
Полностью согласен с ababo, но хотел бы еще спросить: а не думали сделать отдельные сборщики на каждый процесс свой, плюс один системный, который будет чистить закончившиеся процессы?
ИМХО, так было бы проще, чем городить «всемирный» сборщик. При этом, «процессный» сборщик и приостанавливать процесс может (отдельно от системы) и что угодно другое творить. Как в обычной Яве и других JVM.
ИМХО, так было бы проще, чем городить «всемирный» сборщик. При этом, «процессный» сборщик и приостанавливать процесс может (отдельно от системы) и что угодно другое творить. Как в обычной Яве и других JVM.
В настоящее время он реализован на принципе подсчёта числа ссылок на объектЭто же ужас-ужас. Каждая передача указателя куда-либо увеличивает/уменьшает счётчик ссылок, что приводит к засорению L1 кешей процессоров. Надеюсь, этот алгоритм управления памятью не навязывается системой?
А вообще, присоединяюсь к вышесказанному. Зачем сборщик? Если мы не доверяем процессам, они могут наделать утечек памяти и без потерянных ссылок.
Лучше ввести квотирование. Задача в некотором контексте не может выделить больше квоты, а при убиении задачи нужно уметь вернуть системе всё, что это задаче было выделено.
Дима, а где можно почитать о том, как в Фантоме сделаны атомарные снапшоты?
А что предполагается делать с приложениями, у которых просто течёт память? Согласно персистентной модели, приложение запускается один раз и на всю жизнь. Пусть это какой-нибудь Office, в нём пользователь создаёт какие-то документы. Этими документами он обменивается с другими приложениями/устройствами. Но вот память течёт и течёт. Можно ли будет остановить это и не потерять созданные документы? Как это будет выглядеть с точки зрения пользователя?
Согласно персистентной модели, приложение запускается один раз и на всю жизнь.
Тут нужно обратить внимание, что никто не запрещает приложению завершать работу.
«Вся жизнь» — то время, которое необходимо приложению, что бы выполнить полезную для пользователя работу.
Тут нет деления на диски и RAM. Если не хватает RAM, страницы вытесняются на диск, но в адресном пространстве за приложением остаются зарезервированные адреса.
Остановка приложения — это Uninstall.
Остановка приложения — это Uninstall.
Остановка приложения — это Uninstall.
Это как-то очень странно звучит.
Приведу простой пример, который (надеюсь) будет понятен всем:
Приложение, написанное на Java/C#/несуть. Допустим, какая-то обработка данных, которые откуда-то поступают, их как-то обрабатывают, результат обработки — куда-то складывают. Для обработки очередной порции данных, запускают 1-2, да хоть 100500 нитей, из которых в каждый момент времени может получаться довольно замысловатый граф обработки. Но по мере завершения работы, нити останавливают.
До этого места всё понятно?
Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил
Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался. Должен ли быть «запущен» тот кусок кода или нужно «останавливать нить»?
Не знаю, но не вижу никаких проблем поступать хоть так, хоть эдак.
Зависит от того, кому (какому приложению) принадлежит ссылка на объект «документ пользователя». Если текстовый редактор умеет передавать владение объектом, то с одной стороны решается проблема освобождения всей памяти занятой текстовым редактором, с другой — возвращаются файлы, от которых, в том числе, хотели избавиться.
Если развернуть ситуацию — документ становится самодостаточным объектом, и это уже он сам решает кому на себя ссылку давать, то исчезают файлы, но возвращается проблема — что делать с объектом, который «текёт»? Потому что «перезапустить» документ нельзя. Можно только убить.
Если развернуть ситуацию — документ становится самодостаточным объектом, и это уже он сам решает кому на себя ссылку давать, то исчезают файлы, но возвращается проблема — что делать с объектом, который «текёт»? Потому что «перезапустить» документ нельзя. Можно только убить.
«файл» — в данном случае, суть «документ», и конечно, есть же сейчас понятие data class?
Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)
И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.
А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
Не понимаю, как экземпляр data class может чо-то там сам решать, ну разве что только если у него будут в комплекте какие-то ACL, которые что-то там ограничат. В любом случае — он эе откуда-то взялся, его кто-то создал, и ссылку на него куда-то передал. Или вместе с понятием «владение» или просто, расрашил (полайкал, ретвитнул :)
И вот этот data class — он сам по себе протекать не может. В него кто-то может че-то напихивать — да. Но ровно так-же, кто-то другой, должен уметь проверить, че там напихали, и лишние удалить.
А код, который со всем этим работает, по-любому нужно уметь останавливать, хотя бы для того, что бы обновить на новую-свежую версию, которая «уже не протекает»
Потребуется вводить понятие «data class» на уровне ОС.
Иначе кто мешает положить где-то в глубине объекта ссылку на делегат или на класс с виртуальными методами, которые имеют ссылки на код.
Но тут даже дело не в ссылках на код. Концепция Фантом предполагает отсутствие сериализации. А это значит, если программист где-то запутался в ссылках внутри чистого data object, он это сразу не видит. Если бы документ сохранялся в файл, было бы подозрительно, что страница текста весит 200 МБ. Но если любая программа получает ссылку на «корень» объектной модели документа, никто не задумывается, сколько он физически занимает в памяти (да там может половина объёма — общая с ОС (ссылки на стандартные ассеты) и другими документами, поэтому традиционные способы подсчёта размера ошибочны).
Иначе кто мешает положить где-то в глубине объекта ссылку на делегат или на класс с виртуальными методами, которые имеют ссылки на код.
Но тут даже дело не в ссылках на код. Концепция Фантом предполагает отсутствие сериализации. А это значит, если программист где-то запутался в ссылках внутри чистого data object, он это сразу не видит. Если бы документ сохранялся в файл, было бы подозрительно, что страница текста весит 200 МБ. Но если любая программа получает ссылку на «корень» объектной модели документа, никто не задумывается, сколько он физически занимает в памяти (да там может половина объёма — общая с ОС (ссылки на стандартные ассеты) и другими документами, поэтому традиционные способы подсчёта размера ошибочны).
Возьмем, например, String. Это data class? Он может протекать?
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?
«Нет сериализации».
Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»
Что сейчас происходит, если программист забывает какую-то ссылку внутри?
Скорее всего в случае Фантома будет ровно то же самое. И просто «добавить персистентность» и «избавить от сериализации» на уровне системы, не сделает автоматически всех программистов умными.
Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
Инструменты со строгой типизацией помогают человеку меньше ошибаться.
Вывод типов компилятором — помогают меньше писать руками.
Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.
Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
Да и потом, давно уже всю сериализацию генерируют, не?
javaxb, protobuf, и вот это всё.
Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?
Если человек хочет прострелить себе ногу — он её прострелит.
Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать? Там будут виртуальные методы? Или, с другой стороны — нужно ли требовать где-то у таких классов отсутствие виртуальных методов?
«Нет сериализации».
Те же самые String и BinaryTree — их совсем нельзя будет сериализовать? Кто-то запретит мне из них сделать json или xml? Так и представляю, приходит dz и ufm, и грозят пальцем «ай-ай-ай, не сериализуй! Грешно! Будешь всю жизнь в SOAP долбиться!»
Что сейчас происходит, если программист забывает какую-то ссылку внутри?
Скорее всего в случае Фантома будет ровно то же самое. И просто «добавить персистентность» и «избавить от сериализации» на уровне системы, не сделает автоматически всех программистов умными.
Как и «добавь вывод типов» — тоже. Как и «добавь зависимые типы» — тоже не сделает.
Инструменты со строгой типизацией помогают человеку меньше ошибаться.
Вывод типов компилятором — помогают меньше писать руками.
Зависимые типы — позволяют исключить еще целый класс ошибок, и еще меньше писать руками. Чем больше вы добавляете мозгов/математики инструменту на уровне концепции, чем больше инструмент может проверить, по сути сужая область в которой программист может нафигачить — тем меньше ошибок.
Но персистентность — это ведь ортогональная штука ко всему этому. Отсутствие сериализации — это просто выкидывание целого класса тупой работы. Это уменьшает количество ошибок, но не концептуально, а рутинно — меньше работы — меньше ошибок.
Да и потом, давно уже всю сериализацию генерируют, не?
javaxb, protobuf, и вот это всё.
Но если у меня есть «документ», как суть, как понятие, он же как-то будет в системе представлен? Будет это data class, или будет это вполне себе smart class — у которого будет внутри какого-то метода while true, но не такой явный, который моймает компилятор, а заумный?
Если человек хочет прострелить себе ногу — он её прострелит.
Могу только повторить тот пример, с которого начал — представьте сейчас любую программу на managed платформе, у которой внутри запускаются отдельные потоки. Вот это примерно то же самое. Просто у современных программ есть какие-то отдельные концепции типа «файл», «база данных», «сеть», а Фантому эти концепции ненужны. И просто не нужно будет мне из какого-то BinaryTree, делать BinaryTreeJson, но не потому, что dz меня предаст анафеме, а просто с точки зрения здравого смысла — зачем заниматьая какой-то фигнёй, если можно прям сам объект отдать, и там всё правильно поймут?
Возьмем, например, String. Это data class? Он может протекать?А что насчёт
Возьмем, например, какой-нибудь BinaryTree. Это будет data class? Оно сможет протекать?
List«object»? В глубинах какого-нибудь ExcelDocument? Когда программист случайно добавил не объект из документа, а какую-то ненужную временную структуру? Или, типичная ошибка — подписал объект «документ» на получение событий «кнопка нажата», тем самым завязав документ на класс окна, который его редактирует (окно не будет освобождено, пока жив документ).При сериализации в обычный файл это сразу всплывает — нарушение формата (а при ручной сериализации вспомогательные поля документа, которые не должны попадать в файл, тупо не будут записаны).
Что сейчас происходит, если программист забывает какую-то ссылку внутри?Сейчас утечка памяти живёт до закрытия приложения. Если файловой системы нет, утечки не на виду.
Скорее всего в случае Фантома будет ровно то же самое.
Если человек хочет прострелить себе ногу — он её прострелит.Разумеется. Утечки будут всегда (любой новичок в программировании напишет с ошибками). Вопрос был в том, не является ли архитектура Фантом особенно к ним уязвимой.
Вот простые сценарии. Программист кладёт undo-операции в документ, но ограничение на длину undo реализовано с ошибкой. Как ловить? Или любой документ, когда-либо открытый редактором, попадает в recent-list, который нигде в интерфейсе не виден. Открываешь файл, редактируешь, нажимаешь «удалить», файл отовсюду из интерфейса пропадает, но память не освободилась.
Сейчас утечка памяти живёт до закрытия приложения. Если файловой системы нет, утечки не на виду.
Если утечка не на виду, может это и не утечка вовсе?
Вопрос был в том, не является ли архитектура Фантом особенно к ним уязвимой.
Не думаю, что есть какая-то заметная разница, в сравнении с обычным приложением, если не рассматривать связи этого приложения и его окружения.
Хотя, за счет более стройной архитектуры в целом, может оказаться, что инструментарий для мониторинга/анализа и может быть даже автоматических каких-то реакций в таких ситуациях, будет проще реализовать.
Если утечка не на виду, может это и не утечка вовсе?Миллион раз повторил действия — память кончилась, но для юзера занятая сейчас память не приносит пользы — типичная утечка.
Не думаю, что есть какая-то заметная разница, в сравнении с обычным приложениемРазница в том, что при закрытии приложение освобождает утекшие ресурсы, либо переносит их в файлы, что очень заметно. В фантоме нет файлов, утечки не видны.
Разница в том, что при закрытии приложение освобождает утекшие ресурсы
прошу еще раз посмотреть на аналогию. В случае фантома «закрытие приложения» — это суть «завершилась нить» в тех приложениях которые сейчас.
Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.
Сейчас, например у jre память можно жестко ограничить при запуске, и процесс внутри, будет получать отлупы.
Всё ровно то же будет происходить в Фантоме, никакой качественной разницы не будет.
То, что условно памяти станет несколько ТБ, я заметной разницей не считаю ;)
Попробую совсем тезисов: архитектура фантома не дает каких-то там заметных преимуществ в автоматическом управлении ресурсами. Наличие мозга у программиста всё еще требуется, аккуратность работы — всё еще важна важна. В то же время, каких-то заметных недостатков тоже нет — если программист с мозгом и аккуратен, на него не свалятся какие-то внезапные проблемы.
Куда переносятся какие ресурсы из нити? Вот будет всё то же самое.В вашем гипотетическом примере такая же текучая архитектура с нитями, когда все нити живут в одном процессе.
Остановка нити возвращает ОС только её стек, а всё остальное — хендлы, выделенная память и т.п. может течь.
В современном юзерспейсе принято запускать процессы. Когда завершается процесс, его ресурсы легко вернуть ОС.
Сейчас, например у jre память можно жестко ограничить при запускеВвести квотирование было моим первым предложением, но чуть подумав, я понял, что не всё там просто. Если приложение А выделяет память для документа и передаёт документ приложению Б, в чью квоту оно теперь переходит, непонятно. Квотирование препятствует свободному расшариванию данных.
этот мой «гипотетический пример» — он везде вокруг. По крайней мере, пока Фантом не начал массовый захват мира ;)
Но вы опять по какую-то ОС — забудьте. В случае Фантома, если довольно грубо, то ОС — это современная программа. Программы Фантома — нити внутри современной программы. Нить возвращает программе стек? Остальные все ресурсы во владении самой программы? Вот так и будет в Фантоме. Нет никакого ни юзер- ни другого спейса. Прослойка VM и сразу железо.
Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
Но вы опять по какую-то ОС — забудьте. В случае Фантома, если довольно грубо, то ОС — это современная программа. Программы Фантома — нити внутри современной программы. Нить возвращает программе стек? Остальные все ресурсы во владении самой программы? Вот так и будет в Фантоме. Нет никакого ни юзер- ни другого спейса. Прослойка VM и сразу железо.
Если вы сейчас в программе запускаете нить, что бы она сделала для вас полезную работу, нить в ходе этого нажрала гигабайты памяти, что происходит?
Либо, ссылка на эти гигабайты осталась в стеке, после освобождения стека протухла, и гигабайты подберет сборщик мусора, или нить отдала «полезное нажратое» вам в качестве результата — «на, слушай, сам выкинь, да!» (анекдот про бумеранг)
этот мой «гипотетический пример» — он везде вокруг.Именно так. Только программы периодически перезапускают. Тот же Firefox я перезапускаю раз в 2-4 недели, без этого он начинает тормозить.
Отсюда и вопрос, который задан выше: если Фантом захватит мир, как бороться с утечками при невозможности рестарта процесса.
Только программы периодически перезапускают.
…
при невозможности рестарта процесса
Любой объект можно создать когда нужно, а когда не нужно — убить.
С чего вдруг какие-то процессы в Фантоме станут неубиваемые или неперезапускаемые? Кто запретит? Таки лично dz будет приходить и говорить, что грешно процессы перезапускать?
Особенно странно звучит эта гипотеза в рамках концепции платформы, которая принципиально 100% managed.
Автор на эту тему прямо не писал, но я понял, что процессов в традиционном понимании в этой ОС нет, а вы (возможно) считаете, что они есть.
На эту тему автор пишет уже больше десяти (двадцати?) лет, в разных местах.
Вот у вас сейчас, в классической ОС, программа — это такой файл на диске. Она «остановлена»? Что случается, если вы её «запускаете»? Просто подумайте. А теперь представьте, что диска как такового нет — всё некая память, которая не пропадает сама по себе. Как изменится ваш ответ на тему «запуск программы»?
Разница между «запущенной программой» и «незапущенной», только в простом факте: «запущенная» программа получает некие события «извне», и может сама какие-то события генерировать, и куда-то там отправлять. Например запросить кусок памяти, обратиться по сети к какой-то другой программе.
Что означает для программы «завершила работу»? Перестала обрабатывать события извне. По своей внутренней воле. И перестала сама генерировать события. Последнее событие, которое она сгененрировала — сообщила системе — system.exit(0)
процессов в традиционном понимании в этой ОС нет
Вот у вас сейчас, в классической ОС, программа — это такой файл на диске. Она «остановлена»? Что случается, если вы её «запускаете»? Просто подумайте. А теперь представьте, что диска как такового нет — всё некая память, которая не пропадает сама по себе. Как изменится ваш ответ на тему «запуск программы»?
Разница между «запущенной программой» и «незапущенной», только в простом факте: «запущенная» программа получает некие события «извне», и может сама какие-то события генерировать, и куда-то там отправлять. Например запросить кусок памяти, обратиться по сети к какой-то другой программе.
Что означает для программы «завершила работу»? Перестала обрабатывать события извне. По своей внутренней воле. И перестала сама генерировать события. Последнее событие, которое она сгененрировала — сообщила системе — system.exit(0)
На эту тему автор пишет уже больше десяти (двадцати?) лет, в разных местах.Если вы следите за темой, дайте ссылку на наиболее полное описание концепции.
Разница между «запущенной программой» и «незапущенной», только в простом факте: «запущенная» программа получает некие события «извне», и может сама какие-то события генерировать, и куда-то там отправлятьЗапущенная программа имеет процесс, который владеет ресурсами ОС.
Что означает для программы «завершила работу»? Перестала обрабатывать события извне. По своей внутренней воле.А также освободила ресурсы, которыми владел процесс.
я сходу не знаю какой-то одной ссылки, если dz знает — может сам выдаст.
«Процесс» — это такая запись в таблице процессов? А этот самый PID — это номер этой записи? Есть еще что-то важное? Область памяти в которую загружен код, какие-то стандартные дескрипторы stdin, stdout — это всё не важно. Это по сути тоже какие-то данные в той же таблице, которые можно узнать, зная PID.
Что значит «владеет ресурсами»? Вот, в программе вызывают malloc(), что дальше происходит? Понятно, что основной результат — адрес блока памяти. Но что значит «владеет ресурсами ОС»?
Если ОС память выдает, то в той самой «таблице процессов» находит PID откуда пришел malloc(), и записывает «выдано памяти, по такому-то адресу, такого-то размера». То есть, «процесс владеет ресурсами ОС» — это тоже тупо запись в каких-то структурах данных внутри ОС, связанных с этим PID?
Что значит «освободила ресурсы»? Отправила программа в ОС «сообщение»" free()? Никто не заставляет программу освобождать память, перед тем как сказать system.exit()? Что в этом случае происходит? ОС смотрит в те самые таблицы-итд, находит там PID, находит все ресурсы с ним связанные, выполняет какие-то манипуляции с этими дескрипторами, размерами и так далее. Так?
Что вообще такое «освобождение памяти»? Это отметка, что начиная с такого-то адреса, такой размер блока — свободен. Отметка, опять таки, в какой-то структуре внутри ОС. Как это сейчас принято делать, списки? Деревья?
То есть, всё вот это — это просто изменение данных в системных структурах. Больше никаких физических действий не происходит.
Что изменятся если у нас диск от ОЗУ неотличим? Правильно — ни-че-го.
И это «неотличимо» работает давно, называется «виртуальная память». Если верить википедии, понятие «Вритуальная память» существует с 1956 года. На практике используется с 1969.
То есть, какова бы ни была среда выполнения, ОС (эта самая среда),
— запускает процессы
— выделяет им ресурсы — malloc
— умет освобождать конкретные ресурсы по просьбе процесса — free
— умеет освобождать все ресурсы, по завершению процесса — я думаю, что сама запускает free по всему списку
И мы только что разобрались, что всё это, просто суть данные в каких-то таблицах/списках/деревьяъ/структурах, как там оно реализовано.
Что такое «протекаюзщая программа»? Программа, которая не вызвает free. Но с точки зрения ОС, это означает, что где-то там в её структурах, есть данные про эти куски памяти. И как только программа говорит system.exit() — ОС знает, все эти ресурсы свободны, и сама вызывает free.
Кто или что помешает в ОС Фантом реализовать system.exit()?
Запущенная программа имеет процесс, который владеет ресурсами ОС.
«Процесс» — это такая запись в таблице процессов? А этот самый PID — это номер этой записи? Есть еще что-то важное? Область памяти в которую загружен код, какие-то стандартные дескрипторы stdin, stdout — это всё не важно. Это по сути тоже какие-то данные в той же таблице, которые можно узнать, зная PID.
Что значит «владеет ресурсами»? Вот, в программе вызывают malloc(), что дальше происходит? Понятно, что основной результат — адрес блока памяти. Но что значит «владеет ресурсами ОС»?
Если ОС память выдает, то в той самой «таблице процессов» находит PID откуда пришел malloc(), и записывает «выдано памяти, по такому-то адресу, такого-то размера». То есть, «процесс владеет ресурсами ОС» — это тоже тупо запись в каких-то структурах данных внутри ОС, связанных с этим PID?
Что значит «освободила ресурсы»? Отправила программа в ОС «сообщение»" free()? Никто не заставляет программу освобождать память, перед тем как сказать system.exit()? Что в этом случае происходит? ОС смотрит в те самые таблицы-итд, находит там PID, находит все ресурсы с ним связанные, выполняет какие-то манипуляции с этими дескрипторами, размерами и так далее. Так?
Что вообще такое «освобождение памяти»? Это отметка, что начиная с такого-то адреса, такой размер блока — свободен. Отметка, опять таки, в какой-то структуре внутри ОС. Как это сейчас принято делать, списки? Деревья?
То есть, всё вот это — это просто изменение данных в системных структурах. Больше никаких физических действий не происходит.
Что изменятся если у нас диск от ОЗУ неотличим? Правильно — ни-че-го.
И это «неотличимо» работает давно, называется «виртуальная память». Если верить википедии, понятие «Вритуальная память» существует с 1956 года. На практике используется с 1969.
То есть, какова бы ни была среда выполнения, ОС (эта самая среда),
— запускает процессы
— выделяет им ресурсы — malloc
— умет освобождать конкретные ресурсы по просьбе процесса — free
— умеет освобождать все ресурсы, по завершению процесса — я думаю, что сама запускает free по всему списку
И мы только что разобрались, что всё это, просто суть данные в каких-то таблицах/списках/деревьяъ/структурах, как там оно реализовано.
Что такое «протекаюзщая программа»? Программа, которая не вызвает free. Но с точки зрения ОС, это означает, что где-то там в её структурах, есть данные про эти куски памяти. И как только программа говорит system.exit() — ОС знает, все эти ресурсы свободны, и сама вызывает free.
Кто или что помешает в ОС Фантом реализовать system.exit()?
Разница в том, что обычные ОС делают копию данных, передавая их во владению процессу (да, та самая сериализация/десериализация в файлы).
Вы предлагаете каждому ресурсу добавить метку — PID владельца.
Если от сериализации отказываться, то как будет выглядеть открытие документа?
Вот есть документ в памяти, сейчас его владелец — ОС. Документ передали на редактирование какому-то приложению, что произойдёт?
Процесс приложения при редактировании выделил у менеджера памяти пару новых блоков и добавил их в объект документа. Кто владелец новых блоков? Что с ними произойдёт при убиении процесса?
Вы предлагаете каждому ресурсу добавить метку — PID владельца.
Если от сериализации отказываться, то как будет выглядеть открытие документа?
Вот есть документ в памяти, сейчас его владелец — ОС. Документ передали на редактирование какому-то приложению, что произойдёт?
Процесс приложения при редактировании выделил у менеджера памяти пару новых блоков и добавил их в объект документа. Кто владелец новых блоков? Что с ними произойдёт при убиении процесса?
как это копирование или некопирование данных влияет?
это не я предлагаю. Вот, у меня windows вокруг, там есть такая утилита ProcessExplorer, которая залезает во внуренности системы, и показывает очень много чего. Мне, на самом деле, не важно технически, как именно это сделано, потому, что совершенно очевидно, всё это начинается со списка процессов, и далее там как-то к этим процессам подвязано.
Отличный вопрос. Вот у вас есть в программе, в памяти объект. Вы вызываете некую функцию обработки, и передаете этой функции ссылку на этот объект. Что происходит?
Вот та функция внутри программы внутри jvm/.Net/итд (которой дали ссылку на объект) запросил еще памяти, ему выдали, что происходит? Кто владелец новых блоков?
Могу сходу ответить на «что происходит после завершения функции» — если эти ссылки из этой функции никому больше не попали (функция не отдала эту ссылку в результатах своей работы), у них будет ref count = 0, и эти блоки освободит сборщик мусора.
Вы предлагаете каждому ресурсу добавить метку — PID владельца.
это не я предлагаю. Вот, у меня windows вокруг, там есть такая утилита ProcessExplorer, которая залезает во внуренности системы, и показывает очень много чего. Мне, на самом деле, не важно технически, как именно это сделано, потому, что совершенно очевидно, всё это начинается со списка процессов, и далее там как-то к этим процессам подвязано.
Вот есть документ в памяти, сейчас его владелец — ОС. Документ передали на редактирование какому-то приложению, что произойдёт?
Отличный вопрос. Вот у вас есть в программе, в памяти объект. Вы вызываете некую функцию обработки, и передаете этой функции ссылку на этот объект. Что происходит?
Процесс приложения при редактировании выделил у менеджера памяти пару новых блоков и добавил их в объект документа. Кто владелец новых блоков? Что с ними произойдёт при убиении процесса?
Вот та функция внутри программы внутри jvm/.Net/итд (которой дали ссылку на объект) запросил еще памяти, ему выдали, что происходит? Кто владелец новых блоков?
Могу сходу ответить на «что происходит после завершения функции» — если эти ссылки из этой функции никому больше не попали (функция не отдала эту ссылку в результатах своей работы), у них будет ref count = 0, и эти блоки освободит сборщик мусора.
как это копирование или некопирование данных влияет?Это самое важное, водораздел между обычными ОС и Фантомом — нужны ли копирование/сериализация или не нужны.
Вот у вас есть в программе, в памяти объект. Вы вызываете некую функцию обработки, и передаете этой функции ссылку на этот объект. Что происходит?С точки зрения владения — ничего не происходит.
запросил еще памяти, ему выдали, что происходит? Кто владелец новых блоков?Ресурсы, занимаемые объектом до и после вызова функции принадлежат процессу и будут освобождены при завершении процесса, с потерей несохранённых данных.
это не я предлагаю. Вот, у меня windows вокруг, там есть такая утилита ProcessExplorer, которая залезает во внуренности системы, и показывает очень много чего.В системе Фантом вы не видите никаких серьёзных проблем со ссылками, поэтому я предполагаю, что у вас в голове есть какая-то модель её функционирования.
Поэтому и возникают вопросы:
1) Как по-вашему, каждый выделенный блок памяти имеет владельца? (процесс или что-то ещё). Windows с его ProcessExplorer не интересует, интересно мнение, каким вы видите Фантом.
2) Если ответ на 1) — «да», то при завершении процесса блоки памяти, принадлежащие ему, освобождаются?
3) Тот же вопрос, но если на них есть ссылки из блоков, принадлежащих другим процессам? (в традиционных ОС эта ситуация невозможна, т.к. нельзя сделать ссылку из объекта одного процесса на объект, который находится в адресном пространстве другого процесса).
Могу сходу ответить на «что происходит после завершения функции» — если эти ссылки из этой функции никому больше не попали (функция не отдала эту ссылку в результатах своей работы), у них будет ref count = 0, и эти блоки освободит сборщик мусора.Я попробую это осмыслить, когда вы поясните по предыдущим пунктам. Пока у меня получается противоречивая картинка.
В системе Фантом вы не видите никаких серьёзных проблем со ссылками, поэтому я предполагаю, что у вас в голове есть какая-то модель её функционирования.
повторюсь: ОС Фантом на одном физическом хосте — это (грубо) одна копия jvm/.net или любой другой VM. А разные программы в ОС Фантом — это суть разные нити внутри этой самой jvm. Есть сейчас какие-то вопросы по управлению ресурсами внутри одной копии jvm? Примерно такой-же набор вопросов в ОС Фантом.
Ключевое отличие от текущей ситуации с jvm:
— если вы однажды сказали new SomeClass — вам не нужно предпринимать какие-то дополнитлеьные усилия по его сохранению/восстановлению между перезапусками самой системы — это делает ОС сама.
— память-диск-сеть — для вашего процесса представляется единым API, который суть просто передать ссылку на объект.
Само по себе persistance никакой не прорыв — есть в каком-то виде наверное вообще для всего.
Сетевая прозрачность тоже давно известная штука, у jvm есть RMI, например. У того же erlang сетевая прозрачность вообще в базовой концепции. Наверняка можно найти еще примеров успешных промышленных реализаций в этом направлении для других популярных инструментов.
Разница только в том, что в Фантом дадут всё это сразу, в удобном виде, как базовое API.
Навскидку, если сейчас на jvm взять комплект akka + akka-cluster + akka-persistance, то можно с помощью напильника и какой-то матери получить примерно такую же среду выполнения как планируется в Фантоме. Список современных инструментов, у которых разное проникновение в промышленность, и для которых в виде библиотек реалихзована персистентность и сетевая прозрачность можно продолжать.
ответы
1. конечно, у каждого ресурса есть владелец
2. при завершении процесса, сборщик мусора освободит все ресурсы, которыми владел процесс
3. Очевидно, что если владелец передал ссылку на ресурс куда-то наружу, но не передал (разделил?) право владения, то возникает вопрос выбора — что с этим ресурсом делать.
Сборку мусора по счетчику ссылок, в терминах владения можно сформулировать так: если объект получил у «системы» ресурс, и передал ссылку на него в другой объект — то в этот момент он разделил право владения ресурса с тем другим объектом. У ресурса число ссылок — суть число владельцев.
Посмотрите на Rust, из того, что сейчас на слуху, это самое интересное место, где люди пытаются вот эти вопросы владения/передачи как-то красиво формализовать, что бы обеспечить автоматическое управление ресурсами.
ОС Фантом на одном физическом хосте — это (грубо) одна копия jvm/.net или любой другой VM. А разные программы в ОС Фантом — это суть разные нити внутри этой самой jvmПроцессы как объекты ОС тут рудиментарны. Если хочется логически сгруппировать нити в одну сущность и дать им возможность обмениваться данными, то достаточно создать объект в памяти класса Process, в котором будут ссылки на данные, и ссылку на этот объект передать в стеки всех нитей.
Если ОС решает убить процесс, она останавливает нити и обнуляет свою ссылку на Process. Но при этом, если процесс включил ссылку на объект Process в какой-то документ, и отдал этот документ другому процессу, ресурсы первого процесса освободить нельзя.
Есть сейчас какие-то вопросы по управлению ресурсами внутри одной копии jvm?Конечно, есть. Это серверные приложения вылизаны донельзя и не текут (почти). Но и их бывает надо перезапускать. При этом состояние надёжно сохранено в файлах, и перезапуск не приводит к потере данных.
Если в одну песочницу jvm пускать и системные задачи, и браузеры, и игры, и приложения Васи Пупкина, долго эта vm не проживёт.
конечно, у каждого ресурса есть владелец
если объект получил у «системы» ресурс, и передал ссылку на него в другой объект — то в этот момент он разделил право владения ресурса с тем другим объектомВ такой формулировке явная метка владельца не нужна (если единственный владелец убит, ресурс будет освобождён сборщиком, а если владельцев много, их список не поможет ОС в управлении ресурсом). Концептуально можно считать, что список владельцев есть, фактически вести его не надо.
То есть, убить процесс (гарантированно освободить его ресурсы) нельзя, т.к. он может [ошибочно] пошарить чуть ли не все свои данные с другим процессом.
поле «владелец» есть у каждого объекта, да. Может быть, это оверкилл, на самом деле.
Процессов на уровне ядра нет, но процесс — это просто суммарный стейт для группы нитей. Можно реализовать на объектном уровне.
Да. Это вообще интересная проблема. Хочется в этой связи ввести понятие «периметр» и пытаться управлять попаданием объектов в периметр и трекингом ссылок наружу и внутрь. Собственно, отчасти интерес мой к Фантому вызван желанием дойти до этих проблем и с ними поработать. Умозрительно уже не осиливаю. Кстати, не хотите присоединиться к проекту? Мне нравится ход Ваших мыслей. :)
Всё верно. Ну и передавать владение, конечно, можно. И документ, который течёт, вполне возможен. Но повторюсь ещё раз, он возможен и в windows/unix.
Значит ли, что пользователь сделал Uninstall того куска кода, который отрисовывает окно, документ в нём, обрабатывает события итд? Очевидно — нет. Как был в бинарнике приложения кусок кода — так он там и остался.Тут я имею ввиду, что если нет файлов, где-то в памяти есть список
List<Application> Apps;Apps[i].Show(). Если внутри приложения что-то потекло, остаётся один выход — Apps.RemoveAt(i);Теперь, представьте, вот это гипотетическое приложение — операционка. А одна гипотетическая нить в нем — приложение пользователя. Пользователю прислали документ, он его открыл, что-то в нём исправил сохранил и окно закрылПонятно, что убиение нити освобождает ресурсы, выделенные на её стеке. Но у приложения должен быть и какой-то более глобальный контекст, чтобы нити могли общаться и сохранять общие данные. Вот там-то и можно устроить склад утечек.
Это — верное уточнение. Если утечка находится не в документе, она будет освобождена при остановке приложения. Если в документе — никак. Но это не свойство Фантома, это так и сейчас в любом приложении.
Ну а что вы сейчас можете сделать с программой, у которой файл с её документом при каждом открытии растёт на мегабайт? В общем-то, ничего.
Это не проблема, т.к. файлов на выходе у программ считанные единицы. А вот объектов, которые используются в процессе генерации этих файов — миллиарды. И память для них утекает в каждом первом приложении. В нынешнем мире достаточно прибить процесс и перезапустить его, вуаля — проблема решена. Кажется, что рядом с персистентной моделью памяти в любом случае должна быть какая-то неперсистентная, которую можно безболезненно вайпнуть и не потерять действительнно важные объекты. Либо нужна другая модель виртуальной машины, такая, которая бы by design не допускала утечек памяти. Например, если разделить память на 2 части: персистентные данные (аналог файлов) и неперсистентные (аналог оперативной памяти), то можно попробовать сделать что-то вроде этого:
with (use persistentData) {
// Код для обработки каких-то данных, который ограничен возможностями по передаче ссылок
// на созданные внутри объекты. Все объекты в рамках этого кода могут (и должны) быть удалены
// автоматически, как только обработка завершена.
}На входе и на выходе такого куска кода — объект персистентных данных. Созданные динамические объекты не будут жить дольше, чем живёт этот код, ссылки на них нельзя передать в другие места, не делая объекты персистентными. В общем-то схема получается аналогичная текущей. Правда непонятно тогда, в чём выгода. Можно лишь удалить код сериализации/десериализации, вместо этого пользоваться объектами как есть, иногда маркируя их соответствующими атрибутами.
Дмитрий, приветствую. PMDK может оказаться полезен в Фантоме? Есть документация.
Также в рамках отраслевой ассоциации сетей хранения данных была разработана спецификация модели программирования persistent memory.
Также в рамках отраслевой ассоциации сетей хранения данных была разработана спецификация модели программирования persistent memory.
Sign up to leave a comment.
Фантом: большая сборка мусора