История изменений

Он всегда должен быть нативно изменяемый, чистый интерпретатор без JIT это просто недоделанная VM с JIT, такой интерпретатор может быть нужен для простоты реализации, переносимости, лёгкой встраиваемости или меньшего memory footprint, только без JIT он останется «тормозом». Но изначально у тебя речь шла про си, то есть «в лиспе мы можем обновлять функции, в си - не можем». Это не так.

насколько я знаю, *любое* использование указателя на функцию(кроме прямого вызова) в сишечке == UB. А кроме этого к коду никак не добраться, ибо данные могут быть только в памяти данных, и выход за границы данных это тоже UB. Ну а в интерпретаторах - eval есть везде. Какая разница, выполнять код из текста программы, или откуда-то ещё? Код для интерпретатора это данные. (код для компилятора тоже данные, но запуская программу мы выполняем не компилятор, а саму программу). А JIT тут не причём. В принципе, можно сделать компилятор с изменяемыми данными, но это будет уже не C/C++.

Ты как раз сказал «не могу», то есть как будто это вообще невозможно.

В сишечке невозможно, но есть Over9000 других ЯП, в которых это возможно, и благодаря JIT'у достаточно быстро.

Даже без всякого LLVM можно подключать/отключать soшки с обновляемым кодом по dlopen/dlclose. Так можно делать плагины которые можно подключать и отключать без остановки (и тем более перекомпиляции) приложения.

можно. Ну и что это даёт? Очередной switch/case по уже готовому коду?

Плагины, непрерывная инкрементальная разработка приложений без перезапуска их сервера, инкрементальная разработка вообще (в духе SLIME).

это всё мелочи. Программы работают в старт-стопорном режиме (во всяком случае с т.з. клиентов), потому подменить код можно и без таких извращений.

1. запускаем параллельно второй сервер

2. отправляем запросы на второй

3. ждём, пока первый обработает все запросы

4. отключаем первый.

вот и вся недолга. Первому серверу вовсе не обязательно менять свой код.

Будешь писать VM с байткодом которая, к тому же, будет тормозить? И это при наличии готовых решений.

буду. и тормозить она не будет, потому-что мой байткод будет на решение задачи «ЗАЧЕМ?», а твой готовый - для парсинга яваскрипта на быдлоконтакте.

У JVM байткод это средство переносимости, для HotSpot это всё равно промежуточная стадия до получения нативного кода. Для лиспокодера использующего SBCL в режиме компиляции вообще никакого байткода нет - всюду происходит обновление нативного кода для CPU.

байткод это конечно хорошо... В случае, если нам нужно написать игрушку для Over9000 разных мобил, и нам не потянуть Over9000 компиляций... Но это лишь одна из существующих задач. Часто процессоры однотипные, компилировать нужно 1..2 раза, и разработчик вполне себе может с этим справится, а не валить компиляцию на клиентов. Да ещё и в рантайме.

Он всегда должен быть нативно изменяемый, чистый интерпретатор без JIT это просто недоделанная VM с JIT, такой интерпретатор может быть нужен для простоты реализации, переносимости, лёгкой встраиваемости или меньшего memory footprint, только без JIT он останется «тормозом». Но изначально у тебя речь шла про си, то есть «в лиспе мы можем обновлять функции, в си - не можем». Это не так.

насколько я знаю, *любое* использование указателя на функцию(кроме прямого вызова) в сишечке == UB. А кроме этого к коду никак не добраться, ибо данные могут быть только в памяти данных, и выход за границы данных это тоже UB. Ну а в компиляторах - eval есть везде. Какая разница, выполнять код из текста программы, или откуда-то ещё? Код для интерпретатора это данные. (код для компилятора тоже данные, но запуская программу мы выполняем не компилятор, а саму программу). А JIT тут не причём. В принципе, можно сделать компилятор с изменяемыми данными, но это будет уже не C/C++.

Ты как раз сказал «не могу», то есть как будто это вообще невозможно.

В сишечке невозможно, но есть Over9000 других ЯП, в которых это возможно, и благодаря JIT'у достаточно быстро.

Даже без всякого LLVM можно подключать/отключать soшки с обновляемым кодом по dlopen/dlclose. Так можно делать плагины которые можно подключать и отключать без остановки (и тем более перекомпиляции) приложения.

можно. Ну и что это даёт? Очередной switch/case по уже готовому коду?

Плагины, непрерывная инкрементальная разработка приложений без перезапуска их сервера, инкрементальная разработка вообще (в духе SLIME).

это всё мелочи. Программы работают в старт-стопорном режиме (во всяком случае с т.з. клиентов), потому подменить код можно и без таких извращений.

1. запускаем параллельно второй сервер

2. отправляем запросы на второй

3. ждём, пока первый обработает все запросы

4. отключаем первый.

вот и вся недолга. Первому серверу вовсе не обязательно менять свой код.

Будешь писать VM с байткодом которая, к тому же, будет тормозить? И это при наличии готовых решений.

буду. и тормозить она не будет, потому-что мой байткод будет на решение задачи «ЗАЧЕМ?», а твой готовый - для парсинга яваскрипта на быдлоконтакте.

У JVM байткод это средство переносимости, для HotSpot это всё равно промежуточная стадия до получения нативного кода. Для лиспокодера использующего SBCL в режиме компиляции вообще никакого байткода нет - всюду происходит обновление нативного кода для CPU.

байткод это конечно хорошо... В случае, если нам нужно написать игрушку для Over9000 разных мобил, и нам не потянуть Over9000 компиляций... Но это лишь одна из существующих задач. Часто процессоры однотипные, компилировать нужно 1..2 раза, и разработчик вполне себе может с этим справится, а не валить компиляцию на клиентов. Да ещё и в рантайме.