В Oberon BlackBox есть команда меню позволяющая выгрузить модуль.
В Clojure при загрузке командой require можно указать :reload что конечно не выгрузит модуль полностью, но перегрузит его.
В net fx была возможность убивать дополнительные домены с загруженными в них модулями. В корке к сожалению от этого отказались.
Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения.
По крайней мере в корке через контекст загрузки осуществить выгрузку довольно сложно пока есть ссылки (например был вызван конструктор класса из загруженной сборки).
В ББО как-то с этим попроще, хотя там реализована безопасная выгрузка.
Здравствуйте, Разраб, Вы писали:
Р>Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения.
Это WinAPI для DLL или что-то другое?
Р>По крайней мере в корке через контекст загрузки осуществить выгрузку довольно сложно пока есть ссылки (например был вызван конструктор класса из загруженной сборки).
Ну так это, наверно, нормально.
Р>В ББО как-то с этим попроще, хотя там реализована безопасная выгрузка.
Что такое ББО?
Р>Насколько практична данная фича?
В Erlang это существует чуть ли не с самого начала и активно использовалось, есть аккуратное постепенное применение нового кода и есть поддержка для хуков после смены кода.
Практика, тем не менее, показала, что и с ним сейчас активно предпочитают делать толстые сборки, включая в контейнерах, и перезапускать с ними целиком, вместо того чтобы аккуратно апгредить на ходу.
Здравствуйте, Разраб, Вы писали:
Р>Насколько практична данная фича?
Без контекста сказать невозможно.
В винде прямое управление загрузкой/выгрузкой DLL — основной способ частичной замены кода приложения.
Если пользоваться только загрузкой, без выгрузки, то создаётся
а) нагрузка на адресное пространство (физическая память неиспользуемым кодом не потребляется)
б) блокировка файла от изменений
Первая проблема — не шибко значительна; а вот вторая может помешать проводить всякие манипуляции.
В джаве, насколько я помню, всем рулит сборщик мусора. Если в корнях GC не осталось ссылок на код (то есть нету живых объектов вашего класса, и нет ссылок на его класслоадер), то место, занимаемое байт-кодом и отджиттенным нативным кодом будет освобождено.
Примерно аналогичная штука есть в и в дотнете, хотя она и требует ручного управления.
Коротко:
— при отстутствии такой штуки у приложения могут возникнуть проблемы с динамическим обновлением кода на диске.
— при полностью ручном управлении есть риск поломать приложение — если выгрузить модуль, код которого всё ещё активно используется
— при автоматическом управлении "всё работает само", но выгрузка не является детерминированной (что опять же может создать проблемы с динамическим обновлением кода)
— при полуавтоматическом управлении получаем сочетание всех трудностей одновременно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Разраб, Вы писали:
Р>Насколько практична данная фича?
1. Это же основа плагинной системы — очень удобно.
2. Я таким образом подставляю код, необходимый для работы на текущем оборудовании.
3. Могу отключать модули, которые уже отработали и не нужны.
4. Отложенная загрузка библиотек.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Разраб, Вы писали:
Р>>Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения.
N>Это WinAPI для DLL или что-то другое?
Наверно, редко с винапи сталкиваюсь.
Здравствуйте, Разраб, Вы писали:
Р> Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения.
Это для загрузки/выгрузки dll. Обычный механизм нативного мира. То есть, никакой специфики именно FPC в этом нет.
Р> Насколько практична данная фича?
Загрузка/выгрузка модулей вещь полезная. Например, в Delphi есть понятие пакетов (прообраз дотнетовских сборок). Это такие dll особым образом интегриуемые с основным приложением. На основе этой техники построена непосредственно среда разработки Delphi, где все подсистемы разнесены по пакетам. Например, компиляоры для андроид, виндоус, макос, линукса, айос это все отдельные пакеты. Поддержка визуального проектирования, интеграция с системами контроля версий, всевозможные редакторы и прочее и прочее. На этой же технологии основана интеграция наборов сторонних компонентов.
Здравствуйте, Разраб, Вы писали:
Р>В Oberon BlackBox есть команда меню позволяющая выгрузить модуль. Р>В Clojure при загрузке командой require можно указать :reload что конечно не выгрузит модуль полностью, но перегрузит его. Р>В net fx была возможность убивать дополнительные домены с загруженными в них модулями. В корке к сожалению от этого отказались. Р>Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения. Р>По крайней мере в корке через контекст загрузки осуществить выгрузку довольно сложно пока есть ссылки (например был вызван конструктор класса из загруженной сборки). Р>В ББО как-то с этим попроще, хотя там реализована безопасная выгрузка.
Р>Насколько практична данная фича?
Практична, если ты используешь Compiler-as-a-Service (например, для юзерского скриптинга). На лету собираешь из постоянно меняющегося текста сборку, подгружаешь, а что с ней делать, когда она протухла? Будет утечка. Это я сейчас говорю про дотнет. (И там они ещё, насколько я помню, навертели с дурацкими доменами, не вижу, чтобы оно стало безопаснее, но юзер-скриптинг стало сделать намного труднее — впрочем, я это писал давно, щас, возможно, что-то поменялось).
"LoadLibrary , FreeLibrary" это не "free pascal", а WinAPI. Нужно, чтобы не было утечек, и чтобы не блокировать файлы.
Здравствуйте, Разраб, Вы писали:
Р>Насколько практична данная фича?
Каково соотношение памяти занимаемое кодом к памяти выделяемом приложением в процессе к общей доступной памяти? Если это 1/5/1000000, то видимо не актуально. Если 10/10000/100000, то видимо тоже. А если 100/50/200, т.е. основные затраты памяти — это исполняемый код, то видимо вполне себе практично. Только я таких приложений никогда не видел и не уверен, что они вообще сущетвуют
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Каково соотношение памяти занимаемое кодом к памяти выделяемом приложением в процессе к общей доступной памяти? Если это 1/5/1000000, то видимо не актуально. Если 10/10000/100000, то видимо тоже. А если 100/50/200, т.е. основные затраты памяти — это исполняемый код, то видимо вполне себе практично. Только я таких приложений никогда не видел и не уверен, что они вообще сущетвуют
Либы для CUDA+cuDNN+TensorRT в сумме занимают около 2.5 Гб. Поэтому для них делают отложенную загрузку и выгружают, когда не нужны.
Здравствуйте, Nuzhny, Вы писали:
N>Либы для CUDA+cuDNN+TensorRT в сумме занимают около 2.5 Гб. Поэтому для них делают отложенную загрузку и выгружают, когда не нужны.
Для этого наверное полезно, особенно, если их грузить в какую-нибудь Raspberry Pi.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Каково соотношение памяти занимаемое кодом к памяти выделяемом приложением в процессе к общей доступной памяти? Если это 1/5/1000000, то видимо не актуально. Если 10/10000/100000, то видимо тоже. А если 100/50/200, т.е. основные затраты памяти — это исполняемый код, то видимо вполне себе практично. Только я таких приложений никогда не видел и не уверен, что они вообще сущетвуют
Учитывая что в современных ОС код грузится по необходимости, включённый в общую систему mmap'ом с опциями read+execute+deny_write — ты просто не можешь знать, какая доля реальных затрат на голый объём кода влияет, а какая ещё нет.
Здравствуйте, netch80, Вы писали:
IT>>Каково соотношение памяти занимаемое кодом к памяти выделяемом приложением в процессе к общей доступной памяти? Если это 1/5/1000000, то видимо не актуально. Если 10/10000/100000, то видимо тоже. А если 100/50/200, т.е. основные затраты памяти — это исполняемый код, то видимо вполне себе практично. Только я таких приложений никогда не видел и не уверен, что они вообще сущетвуют
N>Учитывая что в современных ОС код грузится по необходимости, включённый в общую систему mmap'ом с опциями read+execute+deny_write — ты просто не можешь знать, какая доля реальных затрат на голый объём кода влияет, а какая ещё нет.
Думаю, что в виртуальных машинах с этим проще. А проблема выгрузки касалась в первую очередь дотнета — это же он не давал выгружать модули.
Здравствуйте, Разраб, Вы писали:
Р>В Oberon BlackBox есть команда меню позволяющая выгрузить модуль. Р>В Clojure при загрузке командой require можно указать :reload что конечно не выгрузит модуль полностью, но перегрузит его. Р>В net fx была возможность убивать дополнительные домены с загруженными в них модулями. В корке к сожалению от этого отказались. Р>Еще в free pascal есть такой LoadLibrary , FreeLibrary. Не уверен, насчет этого. И насколько это безопасно для приложения. Р>По крайней мере в корке через контекст загрузки осуществить выгрузку довольно сложно пока есть ссылки (например был вызван конструктор класса из загруженной сборки). Р>В ББО как-то с этим попроще, хотя там реализована безопасная выгрузка.
Р>Насколько практична данная фича?
Смотря для чего. Во времена доса когда "640Кб хватит всем" везде были оверлеи — части программы, хранимые на дисках отдельными файлами, которые подгружались когда надо было что-то вызывать.
В винде есть DLL, а в линухе SO. Но они скорее нужны для оптимизации общего потребления памяти программами, чтобы одна и та же DLL\SO в разных процессах отображалась в одну область памяти. Хотя большинство систем плагинов в нативных приложениях и сейчас используют DLL\SO и их механизм выгрузки.
В мире VM и JIT с выгрузкой сложнее. Во-первых VM старается обеспечить целостность ссылок, чтобы нельзя было выгрузить то, на что ссылается другая часть кода, в том числе нельзя выгрузить метаданные класса, когда есть хотя бы один экземпляр класса. С другой стороны загрузка DLL\SO теперь не только отображения образа файла в память, но и создание исполняемого кода из байткода, то есть нужно чтобы при выгрузке удалялось все что было за JITено. Появился еще третий фактор: в VM с развитой системой метаданных и рантайм рефлексии можно из кода плагина много куда получить доступ, поэтому нужна некоторая изоляция если плагины приходят из недоверенных источников. Причем при переходе на x64 фактор экономии памяти стал неважным, а фактор изоляции наоборот вышел на первый план.
В Java, насколько я знаю, все это рулится Класслоадером, он обеспечивает загрузку и выгрузку отдельных классов. В JVM изначально встроена выгрузка классов на которые нет ссылок, потому что Java создавалась еще во времена когда "640Кб хватит всем". Вроде даже изоляция есть.
В .NET FW была (и сейчас есть) такая изоляция в рамках app domain (с ручным приводом). А .NET Core такого не завезли (потому что не слишком актуально). Кроме того, кажись в .NET 4, прикрутили автоматическую выгрузку динамически созданных методов.
В общем в наше время хорошей единицей изоляции является процесс. Во многих языках не предусмотрена какая-либо изоляция кода, поэтому для недоверенного кода создается процесс, который через IPC каналы общается с основным, и внутри себя вызывает недоверенный код.
Для .net сейчас пилят .net isolator — изолированная среда исполнения на базе WebAssemby (WASM). WASM хост (wasi) работает внутри процесса. Причем хост может управлять изоляцией WASM рантайма достаточно легко, а работа внутри WASM по быстродействию не отличается от самого приложения, только кросс-вызовы тормозят. А еще wasm можно подружить с AOT. И естественно весь wasm хост можно выгрузить разом.
Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
Здравствуйте, gandjustas, Вы писали:
G>Для .net сейчас пилят .net isolator — изолированная среда исполнения на базе WebAssemby (WASM). WASM хост (wasi) работает внутри процесса. Причем хост может управлять изоляцией WASM рантайма достаточно легко, а работа внутри WASM по быстродействию не отличается от самого приложения, только кросс-вызовы тормозят. А еще wasm можно подружить с AOT. И естественно весь wasm хост можно выгрузить разом. G>Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
Интересно. Спасибо. Ссылочку добавлю https://github.com/SteveSandersonMS/DotNetIsolator
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>Для .net сейчас пилят .net isolator — изолированная среда исполнения на базе WebAssemby (WASM). WASM хост (wasi) работает внутри процесса. Причем хост может управлять изоляцией WASM рантайма достаточно легко, а работа внутри WASM по быстродействию не отличается от самого приложения, только кросс-вызовы тормозят. А еще wasm можно подружить с AOT. И естественно весь wasm хост можно выгрузить разом. G>Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
В wasm будет нужна полная копия рантайма со своим gc и плюшками? Тогда это такой же костыль как запуск CPython внутри .net/jvm.
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>Для .net сейчас пилят .net isolator — изолированная среда исполнения на базе WebAssemby (WASM). WASM хост (wasi) работает внутри процесса. Причем хост может управлять изоляцией WASM рантайма достаточно легко, а работа внутри WASM по быстродействию не отличается от самого приложения, только кросс-вызовы тормозят. А еще wasm можно подружить с AOT. И естественно весь wasm хост можно выгрузить разом. G>>Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
N>В wasm будет нужна полная копия рантайма со своим gc и плюшками?
Если это managed сборка, то да. Если AOT, то нет. Но aot в текущем виде весит больше чем vm+dll.
N>Тогда это такой же костыль как запуск CPython внутри .net/jvm.
А что не костыль?
Здравствуйте, gandjustas, Вы писали:
N>>Тогда это такой же костыль как запуск CPython внутри .net/jvm. G>А что не костыль?
Была помню в яве хрень на эту тему, похожая на appdomain. И оно вроде даже работало(ет) — в эклипсе плагины можно было перегружать без рестарта, но это не точно.
Непонятно почему .net isolator должен "захватить все", если тут не только zero sharing с сериализацией, как у отдельного процесса, но еще и гимор от двух разных vm. Одну память заколебешься считать — две managed + натив.
G
G>Для .net сейчас пилят .net isolator — изолированная среда исполнения на базе WebAssemby (WASM). WASM хост (wasi) работает внутри процесса. Причем хост может управлять изоляцией WASM рантайма достаточно легко, а работа внутри WASM по быстродействию не отличается от самого приложения, только кросс-вызовы тормозят. А еще wasm можно подружить с AOT. И естественно весь wasm хост можно выгрузить разом. G>Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
А это чистый васм это же тоже будет дотнет? дотнет в дотнете в смысле два сборщика мусора.
Если нам не помогут, то мы тоже никого не пощадим.
