> Вон то не JIT. Просто класс алгоритмов такой. Скоростными дата компрессорами допустим используется.

Критерии работы ПО с памятью определил: https://www.opennet.me/openforum/vsluhforumID3/129886.html#312 если прога им удовлетворяет то работать будет. Но JIT эти критерии исключают полностью.

> > Программы должны предусматривать сборку без JIT кода.
> Да пожалста, соберите себе браузер. А теперь зайдите им на гмыл, мылру, яндекс или что подобное.

Давно туда не ходил. Да и JS отключен для внешнего мира. Google Chromium имеет JS движок без JIT, специально разработали для архитектур с запретом JIT. Можно его пробывать. А вот Mozilla имеет JIT для JS и для поддержки плагинов, код без JIT предоставлять не хочет, ржавчиной занята.

> Data2code transform - вообще не JIT. Это именно генерация кода по входным данным. И выполнение этого как самый быстрый способ получить результат в памяти, как результат работы вот этого кода

Если удовлетворяет критериям корректности, упомянутым выше, то работать будет. Но здесь усматривается другое но, уже не связаное с процессором и работой OS с памятью. Дедушки заповедали нам, что запускать левые бинари система не должна (где-то в MULTIX еще) и сегодня используется кучу средств, начиная с DAC, которые запретят запустить бинарь собраный/скачаный пользователем. Система разрешает запуск только корректно установленного ПО. Но это уже другая история.

> Я в JS потестировал случайно. Не, там не 10% было. Скорее, 10 000% - дождаться загрузки современного почтаря без JIT малореально.

Когда-то была возможность работать без JS, были упрощенные варианты страниц почтовиков, поищи.
А так да, если поставили за цель собирать данные, майнить, шпионить и взламывать с помощью JS, то владелиц сайта может нагадить такой код с JS что и с JIT будет тормозить. Еще раз это делается умышленно чтобы вынудить пользователей использовать JS с JIT и владельци сайтов имели возможность запускать вирусный код на компьютерах клиентов.

> Безопасность это хорошее дополнение, но только не ценой нагибания задач покупателя. А неработа даже вот веб почтаря или игрухи с интенсивным юзом JS в "медленной" логике - покупателя точно не обрадует.

Вот мы обошли круг и вернулись к первоначальному вопросу: инструкцию NX для реализации корректной работы с памятью без потери производительности в RISC-V сделают? Или при разработки процессора RISC-V корпорашки вкладывают деньги только в аппаратные трояны, чтобы иметь возможность изменять память и устанавливать буткиты с виртуализацией для запуска в них пользовательских OS.

Выше писал, что пользователя нагибает не технология безопасности, а жидо-масонские корпорашки:
1. Не включают инструкции NX для реализации корректной работы с памятью без потерь производительности. В место этого включают аппаратные трояны в процессоры. И это типа свободный процессор. Просто верх цэнизма.
2. Умышленно пишут JS код так, чтобы вынудить некоторых пользователей отключить корректно работающие с памятью алгоритмы для запуска кода с JIT.

> По примерно тем же причинам некоторые сильно замороченные вещи типа GRSec/PaX и проч в майнлайн портированы только частично.

Linix изначально старался корректно работать с памятью используя  NX инструкцию процессора i386 и других. А после переезда Тровальдса в САШ этот код с ядра был удален. Тогда пользователи с европы написали анонимно патчи PAX. И этот код Торальдсу в САШ не дадут включить в мейнлайн. Формальные отмазки:
1. PAX патчи анонимны, а от анонима мы ничего брать не будем.
2. Есть и другие реализации защиты памяти. Вот вы к общему знаменателю прийдите сделайте одну и ее включим.

То что с PAX/Grsecurity портировали в ядро линукс не всегда хорошо. Иногда получилось лучше, но в большинстве реализация в Linux есть хуже. Мейнтейнеры ядра в общем не поняли сути технологий защиты PAX/Grsecurity при их реализации в LInux.