Ещё больший процент не знают и не понимает концепцию сегментов в защищенном режиме, имея представление о сегментах на основе сегментов реального режима :-(
Не адрес, а селектор. А селектор (в защищённом режиме) это флаговые биты плюс индекс в таблице — таблице дескрипторов сегментов.
И уже в дескрипторе сегмента хранится базовый адрес сегмента.
так как открыл путь к полноценной поддержке многозадачности
А чем неполноценна многозадачность в 286? В 386 в плане многозадачности появился только режим Virtual 8086 mode. Остальные новые фишки касаются в основном MMU, например, введение страничной организации и дополнительного уровня трансляции адресов (линейных) в физические.
Ютуб уже давно чем-то таким пользуется, пытаясь выделять хейт-спич и не пропускать такие комменты. Приходится проявлять чудеса находчивости в иносказательности, чтобы преодолеть бездумную машинную цензуру. Ведь слово «шлак» может понизить шансы коммента на долгую жизнь — и плевать, что это комментарий к видео про сварку или металлургию.
У вас узкоспециализированный софт. А general-purpose есть? Или не general purpose, а для инженерных систем бытовых и общественных зданий, главным образом для отопления.
У Valtec-а есть расчётный комплекс, но это не то: в нём нет возможности нарисовать схему, он считает только параллельные не ветвящиеся контуры исходя из предположения, что они запитаны, условно говоря, от коллекторов с безграничной возможностью по поставке/поглощению воды.
Кстати, раз уж вы занимаетесь этой тематикой. Неужели нет специализированного софта подобно тому, как в электронике есть симуляторы, которым даёшь схему, а они тебе посчитают токи и напряжения в любой точке?
Как раз наоборот. Если у вас есть доступ к исходникам, вам ничего не надо эмулировать. Вы компилируете исходный код компилятором с таким набором настроек/ключей, что сгенерированный бинарник просто не содержит упоминания неподдерживаемых инструкций.
А вот для готового (чужого) бинарника, который нельзя перекроить и из которого нельзя убрать упоминание и использование неподдерживаемых инструкций, надо делать эмуляцию.
то как тогда это организовать?
Для определённости представим, что мы говорим о Windows. В целевом процессе, который рискует упасть из-за использования несуществующих инструкций, мы устанавливаем SEH-хендлер, а лучше VEH-хендлер, потому что VEH имеет приоритет над SEH и нам не нужно переживать за то, что nested обработчик что-то сделаем с интересующим нас исключением и наш top-level обработчик так и не увидит нужное ему исключение.
Сам по себе код обработчика исключения и код, устанавливающий обработчик исключения, логично разместить в отдельной DLL. Эту DLL можно либо подгрузить в адресное пространство процесса, который мы хотим излечить от хвори, либо модифицровать исполняемый файл, добавив нужную DLL в таблицу импорта. Либо можно занести эту DLL в реестр в специальный раздел, где хранится список DLL, которые подгружаются в любой процесс априори.
Когда выполнение доберётся до места в коде, где употреблена несуществующая инструкция, x86-процессор, встретив эту инструкцию, генерирует аппаратное исключение #UD (с кодом 6). Суть аппаратных исключений в x86-процессоре конечно же в том, что системный софт (то есть ОС) может назначить свои обработчики для таких ситуаций, и конечно же ядро Windows этой возможностью пользуется. Windows в свою очередь аппаратной исключение #UD обрабатывает и генерирует/возбуждает/выбрасывает уже в рамках Windows-вской модели исключений исключение с кодом STATUS_ILLEGAL_INSTRUCTION. Любой прикладной софт может его отловить и как-то отреагировать.
Вот тут-то и нужен наш обработчик исключений, который их всех исключений отфильтровывает исключения с кодом STATUS_ILLEGAL_INSTRUCTION, и если это так, то смотрит, что это за инструкция, и что с этим можно сделать.
Итак, обработчик-фильтр исключений вызван системой, а это значит, что произошло исключение. Обрабоатчик смотрит, что это за исключение. Если это что угодно кроме STATUS_ILLEGAL_INSTRUCTION — обработчик умывает руки и возвращает EXCEPTION_CONTINUE_SEARCH. Если же это именно неподдерживаемая/некорректная инструкция, то обработчик исключения имеет на руках контекст потока (снапшот всех регистров процессора на момент возникнования исключений), поэтому обработчик берёт EIP (я буду называть регистры так, как будто у нас 32-битный процессор) из контекста и смотрит, что же там за машинный код, то есть буквально дизассемблирует его, а точнее просто читает байты по этому адресу и сранивает это с опкодами инструкции(й), которые мы хотим эмулировать, например POPCNT. Если это именно одна из тех инструкций, которые мы хотим эмулировать, обрабработчик собственно берёт и эмулирует её.
Для этого ему нужно просто произвести все те side effect-ы, которые бы сделала сама инструкция, если бы нативно поддерживалась. У обработчика есть структура с контекстом (состоянием всех регистров), поэтому обработчик просто модифицирует нужные регистры так, как это сделала бы инструкция POPCNT (или любая другая). После чего обработчик корректирует в структуре CONTEXT значение регистра EIP, чтобы он указывал на следующую инструкцию (валидную, но может быть и вновь неподдерживаемую), после чего возвращает код EXCEPTION_CONTINUE_EXECUTION. В результате чего выполнение возврвщается как ни в чём не бывало к следующей (вслед за неподдерживаемой) инструкции и продолжается штатным образом.
При таком подходе каждое «натыкание» на неподдерживаемую инструкцию будут генерировать очередной «подрыв мины» в поиском обработчика исключения и выполнением подходящего обработчика. Можно ускорить работу программы, если обработчик будет не просто эмулировать неподдерживамую инструкцию, но и перезаписывать её JMP-инструкций, которая сразу ведёт на код-переходничок, который занимется эмуляцией. В таком случае не будет «самоподрыва» каждый раз при попытке выполнить неподдерживаемую инструкцию: только первая попытка вызовет исключение, а последующий попытки обойдутся уже без исключений, потому что вместо невалидной инструкции процессор будет встречать JMP на кусочек кода, который делает эквивалентные отсутствующей инструкции действия.
Единственное, о чём нужно беспокоиться во втором подходе, это:
Подход с JMP работает только для длинных инструкций. Однобайтовые неподдерживаемые инструкции будет таким образом пропатчить невозможно, а двухбайтовые — крайне тяжело.
Если программа многопоточная, то возможна гонка между двумя обработчиками исключений, которые принялись обрабатывать квази-одновременное возникшие исключения по поводу одного и того же места в коде которые оба хотят пропатчить один и тот же кусочек кода и пытаются сделать это одновременно. Поэтому тут нужно будет либо использовать синхронизацию, либо написать код так, чтобы параллельное пропатчивание одного и того же места никогда не приводило бы ни к чему плохому.
Но в целом, ничего сложного нет. Лет 15 назад я схожим образом эмулировал TLS для потоконебезопасного кода. Код был написан для однопоточного исполнения, а его нужно было использовать в многопоточной среде, а код активно использовал глобальные переменные, которые не были потоко-специфичными. В итоге я «заминировал» секцию данных так, что каждое обращение к ней вызывало исключения, и каждое такое обращение к глобальной переменной я перенаправлял к потоко-специфичной копии это глобальной переменной.
ButПосле просмотра видео от одного зарубежного физика-оптика у меня поменялась картина мира. Основные инсайты после просмотра видео:
Никаких летящих фотонов не существует в привычном нам представлении (в виде летящего шарика или бесконечно малой точки). Распространение света и энергии света в пространстве имеет чисто волновую природу. Это распространение колебаний электромагнитного поля.
Однако это не отменяет того факта, что взаимодействие материи и электромагнитного поля квантуется: обмен энергией между материей и полем происходит только дискретными порциями и носит локализованный характер. Поэтому то, что мы воспринимаем как фотон — это точечное событие когда в какой-то точке пространства материя лишилась кванта энергии и добавила эту энергию к энергии ЭМ-поля (это то, что мы называем испусканием фотона) или точечное событие, когда в какой-то точке пространства энергия дискретной порцией была отнята от поля и сообщена материи.
Тем не менее, само поле не квантуется и не дискретное: величины E и B для электрической и магнитной составляющих поля могут принимать любые значения, то есть являются «аналоговыми» параметрами точки пространства, а не дискретными. Поэтому закон обратных квадратов для расходящейся волны работает и интенсивность волны по мере удаления от условного точечного источника падает плавно, а не ступенчато.
Никакой интерференционной картины от единичного фотона в двухщелевых опытах никто не наблюдал. У одного фотона слишком мало энергии, чтобы создать целую картину (разве что матрица из ФЭУ смогла бы тут чем-то помочь). Наблюдение интерференционной картины это всегда сбор статистики от огромного числа взаимодействий поле-материя. И поскольку явление отъема от электромагнитного поля кванта энергии и поглощения её материей носит вероятностный характер, интерференционная картина просто показывает статистическое распределение вероятности того, что именно в этом месте на этом атоме произойдет квантованный обмен энергией между полем и материей.
Поэтому в двухщелевых опытах, где даже при испускании единичного фотона наблюдали интерференционную картину, и интерпретировали это как парадокс, что фотон пролетает через обе щели одновременно, или что он является одновременно демонстрирует поведение и частицы, и волны, на самом деле «фотон запускали »миллион миллионов раз, и наблюдали в качестве интерференционной картины пространственное распределение вероятности поглощения энергии конкретной точкой материи путем отъема её у электромагнитного поля.
Сами по себе опыты с испусканием одиночного фотона несут в себе коварство из-за способа, которым достигается излучение якобы одиночного фотона. Классический способ в виде источника когерентного излучения в виде лазера, за которым установлена череда нейтрально-серых фильтров, дающих ослабление интенсивности луча ровно настолько, что получившая мощность излучения такова, что, учитывая энергию одного фотона, в любой произвольно взятый момент времени между источником и мишенью должно быть не более 1 фотона, на самом деле дает непрерывную электромагнитную волну чертовски слабой интенсивности (она непрерывна, монохроматична и когерентна по самой природе лазера), что совсем не одно и то же, как если бы фотон испускался в результате спонтанного процесс, например, ядерного распада. Поэтому опыты с неправильным дизайном дают вводящие в заблуждение результаты.
«эмулировать в ОЗУ» само по себе глупая бессмысленная формулировка. А вот эмулировать инструкцию в целом можно: при встрече неизвестной инструкции процессор генерирует соответствующее исключение — используя SEH или VEH его можно отправить, в обработчике оснований проверять место, вызвавшее исключение, и если это POPCNT, то эмулировать её поведение.
Без него тоже всё работало бы, хоть и гораздо более медленно и печально. Тепло всё равно качалось бы из холодного контура в горячий.
Зато если бы нагрева газа при сжатии и охлаждения при расширении вообще не существовало бы в природе, а фазовые переходы работали так же, тепловые машины работали бы столь же хорошо, как и сейчас.
Кроме того, принципиально возможная холодильная машина, работающая на фазовом переходе между твёрдой и жидкой фазой рвёт вашу тезис о том, что клапейроновское уравнение (касающееся только газов) рулит процессом работы тепловой машины. Нет, это просто побочный эффект. А вы предлагаете отказаться от основного эффекта и работать только на подочном.
Это ошибка точного такого же рода, как убеждённость немалого количества людей в том, что времена года на Земле вызваны тем, что орбита Земли не идеально круглая, а эллиптическая, и часть времени Земля нахзодится дальше от Солнца. Само по себе это утверждение про эллиптическую орбиту абсолютно верное, его нельзя называть бредом. И какой-то мизерный вклад в разницу погоды это расстояние от солнца делает. Но смена времён года вызвана абсолютно не этим, а наклоном оси вращения Земли. Вытянутость орбиты и неодинаковость расстояния до Солнца погоды не делают, хотя и и имеют место.
JIT не означает компиляцию в машинный код, JIT означает компиляцию когда приспичит, в противовес компиляции всего и сразу заблаговременно. Сама компиляция не обязательно будет в машинный код целевого процессора, а скорее всего будет в байт-код кастомной виртуальной машины целевого продукта.
которая компилирует исходный код в машинные инструкции, подставляет его в память при выполнении и обеспечивает
Когда такое делали инди-разработчики, антивирусами такие трюки расценивались крайне негативно, и было практически невозможно доказать антивирусным компаниям, что ты не верблюд, не вирусописатель и добиться добавления исключения в алгоритмы/сигнатуры.
А разработчики V8 такое можно. Все разработчики равны, но некоторые равнее.
Отдельный вопрос: как эта генерация кода на лету в нескольких одинаковых инстансах/процессах будет дружить с реюзом страниц физпамяти и реюзом кеша инструкций. Полагаю — что совсем никак. А вот будь сишный код в отдельной DLL/so — всё было бы иначе
Просто представьте, сегодня, когда вес APK достигает по 30–600 Мегабайт, нужно уложиться всего лишь меньше, чем 100 Килобайт.
Вот я как раз не могу представить, как какой-нибудь вшивый Блокнот или вшивый Список покупок может весить 600 Мб, а игру в 100 Кб мне легко проверить.
Но статья удивила меня самим фактом возможности писать прикладные приложения под Андроид на Си. Я думал, что только Java. А возможность писать на Си — прямо интригует, хочется вкатиться. Есть квик-гайд?
Ещё больший процент не знают и не понимает концепцию сегментов в защищенном режиме, имея представление о сегментах на основе сегментов реального режима :-(
Оффтопик
Знакомый ник с форума VBStreets. И аватара всё та же, что и 20 лет над :-)
Не адрес, а селектор. А селектор (в защищённом режиме) это флаговые биты плюс индекс в таблице — таблице дескрипторов сегментов.
И уже в дескрипторе сегмента хранится базовый адрес сегмента.
А чем неполноценна многозадачность в 286? В 386 в плане многозадачности появился только режим Virtual 8086 mode. Остальные новые фишки касаются в основном MMU, например, введение страничной организации и дополнительного уровня трансляции адресов (линейных) в физические.
Так это проблема китайской комнаты.
Женщину вынули — автомат засунули.
Ютуб уже давно чем-то таким пользуется, пытаясь выделять хейт-спич и не пропускать такие комменты. Приходится проявлять чудеса находчивости в иносказательности, чтобы преодолеть бездумную машинную цензуру. Ведь слово «шлак» может понизить шансы коммента на долгую жизнь — и плевать, что это комментарий к видео про сварку или металлургию.
Почему неведомая хрень? Можно для вас и Википедия неведомая хрень?
У вас узкоспециализированный софт. А general-purpose есть? Или не general purpose, а для инженерных систем бытовых и общественных зданий, главным образом для отопления.
У Valtec-а есть расчётный комплекс, но это не то: в нём нет возможности нарисовать схему, он считает только параллельные не ветвящиеся контуры исходя из предположения, что они запитаны, условно говоря, от коллекторов с безграничной возможностью по поставке/поглощению воды.
Кстати, раз уж вы занимаетесь этой тематикой. Неужели нет специализированного софта подобно тому, как в электронике есть симуляторы, которым даёшь схему, а они тебе посчитают токи и напряжения в любой точке?
Почему в маткаде приходится считать?
Увидев в новостной подборке заголовок, думал, автором будет @iMonin...
Как раз наоборот. Если у вас есть доступ к исходникам, вам ничего не надо эмулировать. Вы компилируете исходный код компилятором с таким набором настроек/ключей, что сгенерированный бинарник просто не содержит упоминания неподдерживаемых инструкций.
А вот для готового (чужого) бинарника, который нельзя перекроить и из которого нельзя убрать упоминание и использование неподдерживаемых инструкций, надо делать эмуляцию.
Для определённости представим, что мы говорим о Windows. В целевом процессе, который рискует упасть из-за использования несуществующих инструкций, мы устанавливаем SEH-хендлер, а лучше VEH-хендлер, потому что VEH имеет приоритет над SEH и нам не нужно переживать за то, что nested обработчик что-то сделаем с интересующим нас исключением и наш top-level обработчик так и не увидит нужное ему исключение.
Сам по себе код обработчика исключения и код, устанавливающий обработчик исключения, логично разместить в отдельной DLL. Эту DLL можно либо подгрузить в адресное пространство процесса, который мы хотим излечить от хвори, либо модифицровать исполняемый файл, добавив нужную DLL в таблицу импорта. Либо можно занести эту DLL в реестр в специальный раздел, где хранится список DLL, которые подгружаются в любой процесс априори.
Когда выполнение доберётся до места в коде, где употреблена несуществующая инструкция, x86-процессор, встретив эту инструкцию, генерирует аппаратное исключение #UD (с кодом 6). Суть аппаратных исключений в x86-процессоре конечно же в том, что системный софт (то есть ОС) может назначить свои обработчики для таких ситуаций, и конечно же ядро Windows этой возможностью пользуется. Windows в свою очередь аппаратной исключение #UD обрабатывает и генерирует/возбуждает/выбрасывает уже в рамках Windows-вской модели исключений исключение с кодом STATUS_ILLEGAL_INSTRUCTION. Любой прикладной софт может его отловить и как-то отреагировать.
Вот тут-то и нужен наш обработчик исключений, который их всех исключений отфильтровывает исключения с кодом STATUS_ILLEGAL_INSTRUCTION, и если это так, то смотрит, что это за инструкция, и что с этим можно сделать.
Итак, обработчик-фильтр исключений вызван системой, а это значит, что произошло исключение. Обрабоатчик смотрит, что это за исключение. Если это что угодно кроме STATUS_ILLEGAL_INSTRUCTION — обработчик умывает руки и возвращает EXCEPTION_CONTINUE_SEARCH. Если же это именно неподдерживаемая/некорректная инструкция, то обработчик исключения имеет на руках контекст потока (снапшот всех регистров процессора на момент возникнования исключений), поэтому обработчик берёт EIP (я буду называть регистры так, как будто у нас 32-битный процессор) из контекста и смотрит, что же там за машинный код, то есть буквально дизассемблирует его, а точнее просто читает байты по этому адресу и сранивает это с опкодами инструкции(й), которые мы хотим эмулировать, например POPCNT. Если это именно одна из тех инструкций, которые мы хотим эмулировать, обрабработчик собственно берёт и эмулирует её.
Для этого ему нужно просто произвести все те side effect-ы, которые бы сделала сама инструкция, если бы нативно поддерживалась. У обработчика есть структура с контекстом (состоянием всех регистров), поэтому обработчик просто модифицирует нужные регистры так, как это сделала бы инструкция POPCNT (или любая другая). После чего обработчик корректирует в структуре CONTEXT значение регистра EIP, чтобы он указывал на следующую инструкцию (валидную, но может быть и вновь неподдерживаемую), после чего возвращает код EXCEPTION_CONTINUE_EXECUTION. В результате чего выполнение возврвщается как ни в чём не бывало к следующей (вслед за неподдерживаемой) инструкции и продолжается штатным образом.
При таком подходе каждое «натыкание» на неподдерживаемую инструкцию будут генерировать очередной «подрыв мины» в поиском обработчика исключения и выполнением подходящего обработчика. Можно ускорить работу программы, если обработчик будет не просто эмулировать неподдерживамую инструкцию, но и перезаписывать её JMP-инструкций, которая сразу ведёт на код-переходничок, который занимется эмуляцией. В таком случае не будет «самоподрыва» каждый раз при попытке выполнить неподдерживаемую инструкцию: только первая попытка вызовет исключение, а последующий попытки обойдутся уже без исключений, потому что вместо невалидной инструкции процессор будет встречать JMP на кусочек кода, который делает эквивалентные отсутствующей инструкции действия.
Единственное, о чём нужно беспокоиться во втором подходе, это:
Подход с JMP работает только для длинных инструкций. Однобайтовые неподдерживаемые инструкции будет таким образом пропатчить невозможно, а двухбайтовые — крайне тяжело.
Если программа многопоточная, то возможна гонка между двумя обработчиками исключений, которые принялись обрабатывать квази-одновременное возникшие исключения по поводу одного и того же места в коде которые оба хотят пропатчить один и тот же кусочек кода и пытаются сделать это одновременно. Поэтому тут нужно будет либо использовать синхронизацию, либо написать код так, чтобы параллельное пропатчивание одного и того же места никогда не приводило бы ни к чему плохому.
Но в целом, ничего сложного нет. Лет 15 назад я схожим образом эмулировал TLS для потоконебезопасного кода. Код был написан для однопоточного исполнения, а его нужно было использовать в многопоточной среде, а код активно использовал глобальные переменные, которые не были потоко-специфичными. В итоге я «заминировал» секцию данных так, что каждое обращение к ней вызывало исключения, и каждое такое обращение к глобальной переменной я перенаправлял к потоко-специфичной копии это глобальной переменной.
https://habr.com/ru/articles/682958/
ButПосле просмотра видео от одного зарубежного физика-оптика у меня поменялась картина мира. Основные инсайты после просмотра видео:
Никаких летящих фотонов не существует в привычном нам представлении (в виде летящего шарика или бесконечно малой точки). Распространение света и энергии света в пространстве имеет чисто волновую природу. Это распространение колебаний электромагнитного поля.
Однако это не отменяет того факта, что взаимодействие материи и электромагнитного поля квантуется: обмен энергией между материей и полем происходит только дискретными порциями и носит локализованный характер. Поэтому то, что мы воспринимаем как фотон — это точечное событие когда в какой-то точке пространства материя лишилась кванта энергии и добавила эту энергию к энергии ЭМ-поля (это то, что мы называем испусканием фотона) или точечное событие, когда в какой-то точке пространства энергия дискретной порцией была отнята от поля и сообщена материи.
Тем не менее, само поле не квантуется и не дискретное: величины E и B для электрической и магнитной составляющих поля могут принимать любые значения, то есть являются «аналоговыми» параметрами точки пространства, а не дискретными. Поэтому закон обратных квадратов для расходящейся волны работает и интенсивность волны по мере удаления от условного точечного источника падает плавно, а не ступенчато.
Никакой интерференционной картины от единичного фотона в двухщелевых опытах никто не наблюдал. У одного фотона слишком мало энергии, чтобы создать целую картину (разве что матрица из ФЭУ смогла бы тут чем-то помочь). Наблюдение интерференционной картины это всегда сбор статистики от огромного числа взаимодействий поле-материя. И поскольку явление отъема от электромагнитного поля кванта энергии и поглощения её материей носит вероятностный характер, интерференционная картина просто показывает статистическое распределение вероятности того, что именно в этом месте на этом атоме произойдет квантованный обмен энергией между полем и материей.
Поэтому в двухщелевых опытах, где даже при испускании единичного фотона наблюдали интерференционную картину, и интерпретировали это как парадокс, что фотон пролетает через обе щели одновременно, или что он является одновременно демонстрирует поведение и частицы, и волны, на самом деле «фотон запускали »миллион миллионов раз, и наблюдали в качестве интерференционной картины пространственное распределение вероятности поглощения энергии конкретной точкой материи путем отъема её у электромагнитного поля.
Сами по себе опыты с испусканием одиночного фотона несут в себе коварство из-за способа, которым достигается излучение якобы одиночного фотона. Классический способ в виде источника когерентного излучения в виде лазера, за которым установлена череда нейтрально-серых фильтров, дающих ослабление интенсивности луча ровно настолько, что получившая мощность излучения такова, что, учитывая энергию одного фотона, в любой произвольно взятый момент времени между источником и мишенью должно быть не более 1 фотона, на самом деле дает непрерывную электромагнитную волну чертовски слабой интенсивности (она непрерывна, монохроматична и когерентна по самой природе лазера), что совсем не одно и то же, как если бы фотон испускался в результате спонтанного процесс, например, ядерного распада. Поэтому опыты с неправильным дизайном дают вводящие в заблуждение результаты.
Хотите посмотреть это видео?
С чего ради весь? Эмулировать придется только неподдерживаемые инструкции. Если в коде их нет, то производительность вообще никак не будет затронута.
За первую часть захотелось поставить плюс в карму, за вторую — поставить минус. Удивительное дело, даже не знаешь, как поступить.
«эмулировать в ОЗУ» само по себе глупая бессмысленная формулировка. А вот эмулировать инструкцию в целом можно: при встрече неизвестной инструкции процессор генерирует соответствующее исключение — используя SEH или VEH его можно отправить, в обработчике оснований проверять место, вызвавшее исключение, и если это POPCNT, то эмулировать её поведение.
Ё-мое, вы серьезно?
Гомеоморфно трансформировался из асферического.
О господи, адвокаты дьявола в ветке...
Зато если бы нагрева газа при сжатии и охлаждения при расширении вообще не существовало бы в природе, а фазовые переходы работали так же, тепловые машины работали бы столь же хорошо, как и сейчас.
Кроме того, принципиально возможная холодильная машина, работающая на фазовом переходе между твёрдой и жидкой фазой рвёт вашу тезис о том, что клапейроновское уравнение (касающееся только газов) рулит процессом работы тепловой машины. Нет, это просто побочный эффект. А вы предлагаете отказаться от основного эффекта и работать только на подочном.
Это ошибка точного такого же рода, как убеждённость немалого количества людей в том, что времена года на Земле вызваны тем, что орбита Земли не идеально круглая, а эллиптическая, и часть времени Земля нахзодится дальше от Солнца. Само по себе это утверждение про эллиптическую орбиту абсолютно верное, его нельзя называть бредом. И какой-то мизерный вклад в разницу погоды это расстояние от солнца делает. Но смена времён года вызвана абсолютно не этим, а наклоном оси вращения Земли. Вытянутость орбиты и неодинаковость расстояния до Солнца погоды не делают, хотя и и имеют место.
JIT не означает компиляцию в машинный код, JIT означает компиляцию когда приспичит, в противовес компиляции всего и сразу заблаговременно. Сама компиляция не обязательно будет в машинный код целевого процессора, а скорее всего будет в байт-код кастомной виртуальной машины целевого продукта.
Когда такое делали инди-разработчики, антивирусами такие трюки расценивались крайне негативно, и было практически невозможно доказать антивирусным компаниям, что ты не верблюд, не вирусописатель и добиться добавления исключения в алгоритмы/сигнатуры.
А разработчики V8 такое можно. Все разработчики равны, но некоторые равнее.
Отдельный вопрос: как эта генерация кода на лету в нескольких одинаковых инстансах/процессах будет дружить с реюзом страниц физпамяти и реюзом кеша инструкций. Полагаю — что совсем никак. А вот будь сишный код в отдельной DLL/so — всё было бы иначе
Вот я как раз не могу представить, как какой-нибудь вшивый Блокнот или вшивый Список покупок может весить 600 Мб, а игру в 100 Кб мне легко проверить.
Но статья удивила меня самим фактом возможности писать прикладные приложения под Андроид на Си. Я думал, что только Java. А возможность писать на Си — прямо интригует, хочется вкатиться. Есть квик-гайд?