Виртуализация исполнения машинного кода процессорной архитектуры ARM в Android-x86 окружении (1187396), страница 5
Текст из файла (страница 5)
Здесь надо принимать во внимание, что как уже было сказано выше,в основе своей работы QEMU использует динамическую трансляцию дляотдельных участков кода, что позволяет ему большую часть временивыполнять машинные инструкции гостевого кода с помощью небольшогоколичества инструкций процессора хостовой системы, что влечёт за собойсущественно меньшие накладные расходы по сравнению с полной эмуляциейкаждой из этих инструкций.Можно также заметить, что вплоть до 20-го числа Фибоначчи времяисполнения программы остается практически константным, как дляпредставленного в данной работе эмулятора, так и для QEMU. Это время,необходимое системе эмуляции для того, чтобы начать выполнениемашинных инструкций гостевого кода.
В случае представленного эмулятораможно считать, что это время, необходимое загрузчику для линковкивходной программы и разрешения зависимостей. В данном случае это времяпорядка 0.15 секунд.Однако, как уже было сказано выше, в реальных приложениях гостевойкод в большинстве случаев будет представлять собой лишь прослойку междуJava-кодом и кодом библиотек, код которых, с применением предлагаемойоптимизации, будет исполняться нативно. Для оценки производительности вэтом случае используется программа, содержащая большое количество31вызовов функций для обработки строк из стандартной библиотеки языка С.Также в данном случае быстродействие сравнивается с версией программы,изначально скомпилированной под хостовую систему и запущенной на ней.На Рис. 4 видно, что в случае, когда программа состоит в основном избиблиотечных вызовов, быстродействие эмулятора отстаёт менее чем напорядок. По факту в приведенном тесте гостевая программа в эмуляторевыполняется в 2-3 раза медленнее, чем нативно.
При таком уровнебыстродействияможноговорить,чтоприпроведениидальнейшихоптимизаций данное решение пригодно для использования в десктопныхэмуляторах Android, используемых разработчиками для отладки. Исходя извсего вышесказанного можно сделать вывод, что предлагаемый методэмуляции можно использовать, однако не в качестве самостоятельногорешения, а именно как тонкую прослойку, предоставляющую нативныйинтерфейс для Android-приложений.32Рис.
4. График времени исполнения тестовой программы №2.7. Бинарная трансляцияКак уже было показано ранее, первоначальный экспериментальныхподход с эмуляцией промежуточного машинного кода мог работать сприемлемым быстродействием только в случае, если прослойка коданевелика и основную часть времени нативный код используется для вызовабиблиотечных функций, для которых существуют версии, скомпилированныепод хостовую архитектуру, то есть под х86.
В этому случае быстродействиекода приближается к нативному, ограничения наступают по большей частисо стороны Java-машины.Совсем иначе ведет себя производительность системы в случае, когда33целевое приложение совершает существенную работу в нативном контексте,но при этом без частого вызова внешних библиотек. В этом случаепроисходит пошаговая эмуляция выполнения инструкций машинного кодапроцессорной архитектуры ARM, что влечёт за собой существенную потерюпроизводительности. Разберемся, почему так происходит.В текущей реализации эмулятора после получения опкода происходитпроцедура декодирования инструкции, которая сопоставляет опкоду, либоклассуопкодовинструкцийструктуруданных,необходимыхдлявиртуализации исполнения данной инструкции. Проблема заключается в том,всего валидных инструкций в процессорной архитектуре ARMv7 несколькосотен, что влечёт за собой необходимость использовать некоторыйконтейнер, не нуждающийся в модификации (так как его содержимоефиксированонавсёмпротяженииработыпрограммы),однакообеспечивающим быстрый (асимптотически константный) поиск средиопкодов на предмет нужного.В текущей реализации в качестве такого контейнера была использованамногоуровневая хеш-таблица, которая статически располагается в памяти.Однакоиз-заобъёманабораинструкцийвозниклапроблемасвозникновением коллизий в текущей реализации этой хеш-таблицы.
Вместостандартного подхода для разрешения коллизий с помощью цепочекзначенийбылорешеноиспользоватьподходсиерархическимихеш-таблицами. Это решение с одной стороны обеспечивало схожуюпроизводительность,а с другой позволило семантически разделитьпространство инструкций на классы. И только в таблицах декодированиянижнего уровня применялись цепочки значений для разрешения редкихвозникающих коллизий. Таким образом с программной точки зрения34структура контейнера, содержащего необходимые для виртуализации данныевыглядит так:typedef struct item {item_type_t utype;union {const instr_desc_t *op;struct search_table *tab;list_t*list;} u;} item_t;Отсюда видно, что на каждом уровне таблицы декодирования можетсодержаться либо “лист” дерева, то есть непосредственно описательинструкции, либо список таких описателей, среди которых ищется нужный вслучае возникновения коллизии, либо хеш-таблицы более низкого уровня, вкоторой следует продолжить поиск.Проблема при таком подходе заключается в том, что несмотря на то,что данные в таблицы заносятся статически на этапе компиляции, нетвозможности повлиять на их расположение в памяти.
Это ведёт к большомуколичеству переходов по указателям в память, расположенную далеко другот друга. Самым значимым последствием такого поведения является большоеколичество промахов кэш-памяти, что влечёт за собой сильную просадкупроизводительности, так как в данном случае от производительностипроцессора практически ничего не зависит - в хеш-таблице не применяютсяхеш-функции как таковые, вместо этого в качестве ключа используютсясемантически-значимые части опкодов машинных инструкций.35Таким образом хеширование в данном случае сводится к простомувычислению значения опкода по маске, что производится за считанные тактыпроцессора, в то время как переход в память, которой нет на моментисполнения соответствующего участка кода может повлечь за собой простойпроцессора в течении сотен тактов, если произошёл так называемый промахкэша.
Это ситуация, когда данные по запрашиваемому адресу отсутствуют впамяти и шине данных требуется существенное время, чтобы получить их измедленной (по сравнению с кэшем) оперативной памяти.Вторая проблема состоит в несоответствии разделения опкодовмашинных инструкций и частоты их встречаемости в реальных приложениях.Существующие компиляторы как правило используют характерные паттерныи наборы инструкций, что позволяет выделить подмножество опкодов,которые будут в среднем выполняться на порядки чаще остальныхинструкций. Также существуют довольно крупные классы инструкций,которые могут вовсе не встретиться в приложении, и которые логичнодекодировать отдельно. К таким в первую очередь относятся векторныеинструкции, а также инструкции для работы с числами с плавающей точкой.За счёт того, что как правило в целевом приложении они используютсяблоками из нескольких команд без переходов и ветвлений внутри них можновыделить декодирование инструкций такого класса в отдельную процедуру ииспользовать одноуровневую реализацию хеш-таблицы, минимизировавколичество промахов кеша.К сожалению невозможно доподлинно определить статистику почастоте встречаемости тех или иных инструкций в машинном коде реальныхприложений, особенно учитывая, что NDK в общем случае позволяет36применять в коде вставки ассемблерного кода, что резко расширяетразнообразие применяемых машинных инструкций.
Однако в целяхоптимизации существующей таблицы декодирования было предложенособрать некоторую количественную статистику по частоте встречаемостиинструкций. В качестве целевого приложения в этом экспериментевыступало ядро Linux от этапа загрузки и вплоть до приглашения команднойстроки пользователя (для этих целей применялся system-mode режимэмулятора).С помощью полученной статистики была произведена следующаяоптимизация. Вместо семантически обоснованной иерархической структурыхеш-таблицыбылорешеноперейти к автоматически генерируемойструктуре. В такой хеш-таблица наиболее часто встречающиеся в реальныхприложениях опкоды инструкций должны располагаться на самом верхнемуровне, если представить хеш-таблицу как сильно ветвистое дерево.
Наосновании собранной ранее информации о наиболее часто встречающихсяинструкциях были сгенерированы маски опкодов инструкций, которыемаксимизировали количество часто встречающихся инструкций, для которыхне требуется разрешения коллизий и при этом минимизировало количествоколлизий в таблице верхнего уровня, а также количество инструкций свысоким рейтингом встречаемости, но попавшим в таблицы более низкихуровней.
Важно, что таблицы в данном случае генерируются автоматически иединственнаянеобходимаяинформацияподлежащихдекодированию,атакже—этовесовыенаборинструкций,коэффициентыихвстречаемости. В конечном итоге такой подход привёл к тому, что вабсолютном большинстве случаев декодирование сводится к поиску поодногарговой хеш-таблице за константное время.37Рассмотрим подробнее структуру данных, которая хранится в таблицедекодинга в качестве значений, соответствущим ключам-опкодам машинныхинструкций.typedef struct instr_description {uint32_t mask;uint32_t value;uint32_t nmask;uint32_t nvalue;const char *name;uint32_t weight;struct {emulation_handle_t execute;execute2_t execute2;#if defined(USER_CFA)user_cfa_insn_flags_t user_cfa_flags;void *user_cfa_callback; // meaning depends on flags#endif /* defined(USER_CFA) */#if defined(USER_MODE)regs_usage_handle_t regs_usage_callback;translation_handle_t translator_callback;#endif /* defined(USER_MODE) */};Эта структура содержит все необходимые данные для виртуализацииодной отдельно взятой инструкции, рассмотрим их последовательно.
Впервуюочередьэтотакназываемый“обработчикэмуляции”илиemulation_handle_t execute, который по сути является обычной функцией соследующей сигнатурой:exec_status_t execute(vcpu_t *vcpu, const struct instr_description *instr, op_t op);38Вобщем случае функция принимает на вход некоторый виртуальныйконтекст процессора, отражающий реальную процессорную архитектуруARMv7, описание инструкции, для который в данный момент производитсяэмуляция, а также непосредственно опкод инструкции, который необходимдля получения некоторых особых параметров инструкции, таких как, кпримеру флаги условного исполнения, которые далеко широко применяютсяприавтоматическойгенерациикодакомпиляторамикаксредствоуменьшения количества инструкций ветвления, которые приводят могутприводить к сбросу предсказателей ветвлений в современных процессорах.Именно здесь кроется проблема, связанная с производительностьювиртуализационного решения, заключающегося в эмуляции процессорныхинструкций.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
