>> И в случае pledge, и в случае PaX за гарантии отвечает ядро.
> Нет, в OpenBSD ядро не дает никаких гарантий, оставляя возможность приложениям изменять исполняемый код. Это дыра которую будут использовать вири.
>> В случае pledge, гарантии заказываются из кода программы,
> Это смешно. Гарантии неизменности исполняемого кода должно давать ядро или аппаратно проц.

Прости, но ты пишешь ахинею. Pledge - это системный вызов, как следствие, вся работа по обеспечению гарантий производится в ядре. С каждым новоым вызовом pledge, выданных разрешений может быть _только_ меньше.
Ну да, может быть баг в реализации, ну так он и в PaX может быть.

>> > Были, есть и будут OS общего назначения и прикладные программы которые строго соблюдают правила контроля за оперативный памятью.
>> Только никакого успеха они не имеют (чего нельзя сказать про нишевые решения).
> Среди тех которые ты должен знать упомяну Apple как фирму чьи OS очень строго защищают память.

Если мне не изменяет память, то только в мобильном исполнении. И это закрытая экосистема, где список доступных приложений (и их возможности), в теории, полностью контролируется Apple.

> Самое главное, разработчики поняли, что код с JIT есть небезопасен

Потенциально небезопасен. И многое зависит от реализации.

>> и закономерно обладает меньшей производительностью.
> Это очень спорный вопрос. Вас обманывают воруя безопасность и обещая мнимую производительность!
> Изменения режима исполняемого кода на изменяемый и потом обратно это очень ресурсоемко и врят ли окупится.

Меня никто не обманывает. Про "небезопасность" отсутствия PaX MPROTECT (W^X pt 2) я уже писал - повторяться избыточно.
По поводу ресурсоёмкости и т.п. - это зависит от реализации и требуемых возможностей. В целом, байткод надо транслировать в машинный код примерно 1 раз, далее можно просто выполнять скомпилированное. Ну да, иногда ради бОльшего "динамизма" такой подход может быть и неприемлем.
На производительность, даже не мнимую лично мне скорее пофигу, особенно, если речь о незаметных "на глаз" процентах, особенно если за счёт безопасности, дело не в этом. Дело в том, что всему миру абсолютно наплевать на мои личные хотелки, у разных людей и компаний разные задачи и разные требования. И, к несчастью, реальность такова, что иногда альтернативы решениям с jit нет, а производительности хочется. А писать за свои деньги свою "правильную" альтернативу не хочется. Или денег нет.

> Оптимизация программы в момент компиляции под целевой процессор дает максимум производительности и скорости исполнения. В добавок можно получить гарантию неизменности исполняемого кода- безопасность.

Вашими бы устами да мёд пить.