Содержание к диссертации
Введение
1 Эффективность двоично-транслирующих систем 15
1.1 Двоичная трансляция и перспективные архитектуры вычислительных систем 15
1.2 Оптимизирующие системы двоичной трансляции 23
1.3 Существующие системы двоичной трансляции 29
1.4 Проблемы повышения эффективности 40
1.5 Постановка задачи 42
1.6 Выводы 43
2 Система "Lintel" 45
2.1 Архитектура "Эльбрус" 45
2.2 Схема двоичной трансляции на "Эльбрусе" 49
2.3 Особенности двоично-транслирующей системы "Lintel" 53
2.4 Шаблонная и оптимизирующая трансляции 57
2.5 Результаты 63
2.6 Выводы 66
3 Адаптивность в двоично-транслирующей системе 67
3.1 Проблема адаптивности 67
3.2 Построение адаптивной двоично-транслирующей системы 71
3.3 Двухуровневая реализация 80
3.4 Результаты 83
3.5 Выводы 90
4 База данных кода 91
4.1 Управление памятью в "Lintel" 91
4.2 Хранение двоично-транслированного кода в памяти 92
4.3 Хранение двоично-транслированного кода на внешнем носителе 95
4.4 Структура базы данных кода 98
4.5 Распознавание кода и загрузка 100
4.6 Результаты 104
4.7 Выводы 109
Заключение 111
Литература 114
Приложение 120
- Существующие системы двоичной трансляции
- Особенности двоично-транслирующей системы "Lintel"
- Построение адаптивной двоично-транслирующей системы
- Хранение двоично-транслированного кода на внешнем носителе
Введение к работе
Актуальность работы
Проблема обеспечения двоичной совместимости [1], то есть возможности корректного исполнения кодов, предназначенных для исполнения вычислительными машинами одной архитектуры на вычислительных машинах другой архитектуры, во многом была и остается серьезной преградой на пути развития информационных технологий.
С одной стороны, создание новых микропроцессоров и вычислительных комплексов (ВК) на их базе неизбежно основывается на анализе недостатков предыдущих разработок, и естественным желанием разработчиков является устранение этих недостатков, что подчас требует коренного пересмотра предыдущих решений.
С другой стороны, при выходе на рынок неизбежно встает вопрос о полноте и готовности набора программного обеспечения для этих ВК, его соответствии потребностям и ожиданиям целевой аудитории потребителей. Неудовлетворительное решение этого вопроса фирмой-разработчиком способно моментально перевесить все достоинства нового микропроцессора.
Однако, наделяя новый микропроцессор свойством двоичной совместимости с одной из уже присутствующих на рынке архитектур, разработчики автоматически снимают эту проблему. Новый микропроцессор появляется на рынке вполне законным преемником уже известной архитектуры, наследуя все множество прикладного (а подчас и системного) программного обеспечения, уже написанного и отлаженного к моменту его представления широкой публике. Таким образом, новый микропроцессор может быть немедленно востребован потребителем и прочно занять свое место на рынке.
К сожалению, необходимость выдержать совместимость с ранее созданными поколениями ВК на аппаратном уровне означает по сути невозможность избавиться
от каких-то недостатков и неэффективностей ранних разработок, приводит к дополнительным затратам оборудования, увеличению площади кристалла и энергопотребления, ограничивает возможности программистов, в конечном счете - ограничивает максимально достижимую производительность.
Тем не менее, на протяжении целого ряда лет именно методы аппаратной поддержки использовались для достижения двоичной совместимости между различными архитектурами коммерчески успешных микропроцессоров. Двоичная совместимость на аппаратном уровне стала неотъемлемым атрибутом анонсов новых микропроцессоров, будь то Intel, Sun, AMD или IBM. Разработчики декларируют как минимум совместимость на уровне приложений [2], а как максимум - полную совместимость со всеми ранее созданными кодами для ранних моделей микропроцессоров этого семейства [3].
О масштабах возможных дополнительных затрат на совместимость на аппаратном уровне можно судить по современным микропроцессорам архитектуры IA-32, уже давно [4, 5] превратившихся из микропроцессоров с полным набором команд (CISC) в связку из суперскалярного ядра, представляющего собой микропроцессор с сокращенным набором команд (RISC), и аппаратного перекодировщика команд, разбивающего сложные CISC-инструкции на множество простых RISC-операций, уже непосредственно исполняемых этим ядром.
Однако подобные, весьма сложные, чисто аппаратные средства отнюдь не являются единственным способом обеспечения двоичной совместимости между различными моделями микропроцессоров. Реальную альтернативу им составляет техника двоичной трансляции [6, 7, 8] - высокопроизводительный программный метод обеспечения двоичной совместимости.
Для дальнейшего изложения введем понятие исходной и целевой архитектур. Целевой будем называть архитектуру микропроцессора новой архитектуры, несовместимого с другими архитектурами на уровне аппаратных команд. Исходной же будем называть архитектуру какой-либо из таких архитектур, двоичной совместимости с которой планируется достигать теми или иными методам.
Суть техники двоичной трансляции сводится к декомпозиции последователь-
ностей двоичных кодов исходной архитектуры и преобразованию их в функционально эквивалентные последовательности кодов целевой архитектуры, впоследствии исполняемые на аппаратуре целевой платформы. При этом, в отличие от такого распространенного метода обеспечения двоичной совместимости, как покомандная интерпретация, двоичная трансляция способна достигать достаточно высокой степени эффективности "исполнения" исходных кодов за счет оптимизации создаваемых трансляций1 (что обеспечивается оперированием не отдельными инструкциями в исходном коде, а их последовательностями) и возможности многократного исполнения единожды полученных трансляций.
Техника двоичной трансляции развивается достаточно давно, однако вплоть до недавнего времени она рассматривалась лишь как вспомогательное направление развития архитектуры ВК, как правило призванное облегчить переход конкретной аудитории пользователей на новую архитектуру [9] - то есть как некий фрагментарный подход, не претендующий на универсальность. Ввиду этого не уделялось должного внимания вопросам обеспечения полной семантической адекватности поведения двоично-транслированных кодов своим исходным аналогам, рамки применимости метода чаще всего сужались до двоичной трансляции приложений, а задача оптимизации трансляций решалась по остаточному принципу. Это приводило к созданию проектов, не позволявших говорить ни о высокой производительности, ни о достаточной надежности, ни об универсальности и прозрачности2 работы двоично-транслирующих систем.
На самом же деле, все отмеченные недостатки являлись прежде всего следствиями тех или иных компромиссов, принятых в конкретных реализациях, но никак не техники двоичной трансляции в целом. Так, уже упоминавшиеся современные микропроцессоры архитектуры IA-32 представляют собой фактически аппаратную реализацию двоично-транслирующей системы - двоично-транслирующая машина транслирует исходные CISC-команды в целевые RISC-команды, выполняет пе-
хТермин "трансляция" в технике двоичной трансляции используется как для обозначения действия по переводу кодов исходной платформы в коды целевой платформы, так и для обозначения образующихся в результате этого действия двоично-транслированных кодов.
2Под "прозрачностью" двоично-транслирующей системы понимается сокрытие ее функционирования от конечного пользователя.
реупорядочивание RISC-команд и запускает их исполнение на RISC-машине, обеспечивая впоследствии корректное отображение видимых эффектов CISC-операций в порядке их следования в исходном коде. Следовательно, объективно отсутствуют причины, по которым техника двоичной трансляции не могла бы использоваться в качестве эффективного средства обеспечения двоичной совместимости.
В то же время, от программной реализации двоично-транслирующей системы можно ожидать значительно большей эффективности по сравнению с чисто аппаратной реализацией. Отсутствие сильного ресурсного давления, которое испытывает на себе аппаратная реализация, позволяет проводить значительно более комплексные оптимизации, наблюдать поведение кода на больших отрезках исполнения и хранить обширный запас подготовленных ранее трансляций. К другим преимуществам программной реализации можно отнести снижение объема необходимого оборудования на кристалле, а следовательно - упрощение и ускорения процесса проектирования аппаратуры, обеспечение возможности увеличения тактовой частоты и снижения энергопотребления, возможность использования в качестве целевой платформы сколь угодно требовательной к подготовке кода архитектуры (включая машины с архитектурой широкого командного слова (VLIW) и явным параллелизмом на уровне команд (EPIC [10])), а также достаточно широкие возможности начального выбора и последующего наращивания функциональности уже выпущенного на рынок изделия - от расширения набора поддерживаемых инструкций единственной исходной архитектуры до добавления поддержки совершенно новых исходных архитектур.
Таким образом, наблюдается явное противоречие между очевидными преимуществами техники программной двоичной трансляции и практическими возможностями ранее построенных двоично-транслирующих систем, не способных в полной мере решить задачу обеспечения двоичной совместимости. А следовательно, становится актуальным раскрытие потенциала техники программной двоичной трансляции как метода, позволяющего достичь полной двоичной совместимости с одной или несколькими выбранными архитектурами наиболее эффективным способом, обладая при этом свойствами универсальности и прозрачности для пользователя; ме-
ф тода, дающего предпосылки к созданию архитектуры, максимально нацеленной на достижение высокой скорости обработки данных, в том числе и за счет отказа от сохранения двоичной совместимости с устаревшими архитектурами на аппаратном уровне.
Цель исследования
Целью диссертационной работы являлись анализ организации существующих реализаций двоично-транслирующих систем и последующая разработка методов повышения эффективности двоично-транслирующего процесса. При этом представлялось важным сконцентрироваться на поиске скрытых внутренних резервов в самой технологии двоичной трансляции и, по возможности, не затрагивать вопросов, касающихся конкретных алгоритмов оптимизационных преобразований в двоично-транслированном коде.
В соответствии с этим, были определены следующие задачи диссертационного исследования:
анализ принятых принципов построения двоично-транслирующих систем;
оценка возможностей различных схем двоичной трансляции по наиболее полному удовлетворению потребности в высокоэффективном механизме двоичной совместимости для вновь разрабатываемых высокопроизводительных вычислительных систем;
теоретическая разработка модели двоично-транслирующей системы, опирающейся на полученные результаты;
практическая реализация разработанной модели для архитектуры с явно выраженным параллелизмом команд и механизмами аппаратной поддержки двоичной трансляции.
Научная новизна работы
К составляющим научную новизну диссертационной работы решениям можно отнести:
схему многоуровневой двоичной трансляции с адаптивной коррекцией уровня проводимых оптимизаций на основе динамического анализа поведения исполняемых кодов;
методы повышения эффективности динамической схемы двоичной трансляции посредством частичного пересечения ее функциональности со статической схемой.
Результаты работы, выносимые на защиту
В диссертационной работе рассматриваются и решаются проблемы повышения эффективности функционирования вычислительной платформы, построенной на базе прозрачной высокопроизводительной двоично-транслирующей системы.
В процессе проведения диссертационных исследований автором получены следующие основные новые научные результаты:
разработаны схема и методы построения многоуровневых адаптивных двоично-транслирующих систем;
разработаны и реализованы необходимые механизмы обеспечения адаптивности для двухуровневой двоично-транслирующей системы, включая схему динамического профилирования и несколько схем выделения единиц оптимизирующей трансляции в коде исходной платформы;
разработан и реализован многофункциональный аппарат базы кодов.
Реализованы несколько версий действующих двоично-транслирующих систем, подтверждающих выносимые на защиту результаты. 4
Практическая ценность
Результаты исследований, выполненных по теме диссертации, были реализованы в следующих программных и аппаратных системах:
семейство инструментальных динамических двоичных трансляторов уровня приложений для переноса приложений платформы Solaris/IA-32 на модель микропроцессора "Эльбрус-ЗМ";
семейство динамических двоичных трансляторов уровня виртуальной машины для исполнения произвольных кодов архитектуры IA-32 на архитектуре "Эльбрус-ЗМ", работающих в составе многоязыковой системы программирования "Эльбрус-ЗМ", разработанной в ЗАО МЦСТ;
ВК "Эльбрус-ЗМ", разработанный в ЗАО МЦСТ, обеспечивающий совместимость с архитектурной платформой IA-32 на уровне виртуальной машины.
Апробация
Основные положения диссертационной работы докладывались на следующих научно-технических конференциях:
международная конференция "Региональная Информатика - 2000" (Санкт-Петербург, 2000 г.);
международная конференция "Региональная Информатика - 2002" (Санкт-Петербург, 2002 г.);
международная молодежная научная конференция XXVI Гагаринские чтения (Москва, 2000 г.);
международная молодежная научная конференция XXVII Гагаринские чтения (Москва, 2001 г.); '--}
международная молодежная научная конференция XXVIII Гагаринские чтения (Москва, 2002 г.);
международная молодежная научная конференция XXIX Гагаринские чтения (Москва, 2003 г.);
всероссийская научно-техническая конференция "Новые материалы и технологии" - НМТ-2002 (Москва, 2002 г.).
Кроме того, результаты диссертационной работы докладывались и обсуждались на научно-технических семинарах ЗАО МЦСТ и ИМВС РАН.
Публикации
По теме диссертационной работы опубликованы десять печатных работ:
Ермолович А.В. Динамическое профилирование для двоично-транслирующей системы // Информационные технологии, №3, 2002, с. 9-13.
Ермолович А.В. База кодов как средство повышения эффективности динамической двоично-транслирующей системы // Информационные технологии, №9, 2003, с. 14-22.
Ермолович А.В. Применение базы кодов в динамической двоично-транслирующей системе - Высокопроизводительные вычислительные системы и микропроцессоры, сборник научных трудов, выпуск 4, Мм ИМВС РАН, 2003, с. 55-66.
Ермолович А.В. Системная поддержка динамического двоичного компилятора: управление памятью - Тезисы докладов Международной конференции XXVI Гагаринские чтения, М., 2000.
Ермолович А.В. Технология выделения и последующей оптимизации регионов в двоично-транслируемом коде как средство повышения производительности вновь разрабатываемых систем динамической двоичной трансляции -Тезисы докладов Международной конференции XXVII Гагаринские чтения, М., 2001.
Ермолович А.В. Применение базы данных двоично-транслированного кода для повышения производительности систем динамической двоичной трансляции - Тезисы докладов Международной конференции XXVIII Гагаринские чтения, М., 2002.
Ермолович А.В. Метод выбора глобальных меток в динамически формируемых регионах двоично-транслируемого кода - Тезисы докладов Международной конференции XXIX Гагаринские чтения, М., 2003.
Ермолович А.В. Применение концепции региональной компиляции в динамической компоненте двоично-транслирующей системы - Тезисы докладов Международной конференции "РИ-2000", СПб., 2000.
Ермолович А.В. Специализированная база данных как средство повышения производительности оптимизирующей двоично-транслирующей системы - Тезисы докладов Международной конференции "РИ-2002", СПб., 2002.
10. Ермолович А.В. Поддержка механизма долговременного хранения трансляций для оптимизирующей двоично-транслирующей системы - Тезисы докладов Всероссийской научно-технической конференции НМТ-2002, М., 2002, Том 3, с. 36-37.
Кроме того, имеется патентная заявка США 10/453,448 (в соавторстве) по теме диссертации, поданная 2 июня 2003 года.
Структура и объем работы
Диссертационная работа состоит из введения, четырех глав и заключения.
Первая глава диссертационной работы посвящена рассмотрению двоично-транслирующих систем. Анализируются основные схемы работы двоично-транслирующих систем. Выделяются специфические аспекты оптимизации двоичных кодов. Приводится краткий обзор некоторых широко известных двоично-транслирующих систем. На основе анализа проблемы повышения эффективности работы двоично-транслирующих систем формулируется постановка задачи.
и*
Вторая глава посвящена обзору практической реализации системы двоичной трансляции с аппаратной поддержкой, входящей в состав ВК "Эльбрус-ЗМ" и вобравшей в себя результаты проведенных автором исследований по теме диссертации. В ходе изложения рассматриваются основные особенности построения ВК "Эльбрус-ЗМ", подробно описывается схема работы двоично-транслирующей системы "Lintel". Подчеркиваются основные особенности, выделяющие описываемую двоично-транслирующую систему на фоне предшествующих работ. Приводится сравнительный обзор двух основных методов трансляции, применяемых в "Lintel". В завершение главы приводятся экспериментальные данные, позволяющие оценить достигнутый уровень производительности ВК "Эльбрус-ЗМ".
В третьей главе рассматривается схема построения адаптивной двоично-транслирующей системы. На основании анализа требований обеспечения адаптивности в двоично-транслирующих системах формулируются принципы построения адаптивных двоично-транслирующих систем. Предлагаются методы построения адаптивной динамической двоично-транслирующей системы и приводится обоснование принципов ее функционирования. Сопоставляются возможности применения различных схем сбора профильной информации и методов формирования единиц оптимизирующей трансляции. Рассматривается практическая реализация двухуровневой адаптивной двоично-транслирующей системы на примере "Lintel" и приводятся экспериментальные результаты ее работы.
В четвертой главе рассматривается применение базы данных кода в двоично-транслирующей системе. Описываются общие принципы управления памятью в "Lintel". Рассматривается выстраиваемая в процессе функционирования системы иерархия буферов трансляций в оперативной памяти ВК. Предлагается метод расширения этой иерархии за счет перехода к использованию энергонезависимой памяти ВК. Рассматривается схема построения механизма, реализующего предложенный метод в рамках "Lintel". Описываются апробированные методы распознавания исходных и подкачки двоично-транслированных кодов. Полученные экспериментальным путем результаты работы предложенного механизма сопоставляются с теоретическими оценками.
'4
В заключении формулируются основные результаты, полученные автором на основе исследований, проведенных в диссертационной работе.
Существующие системы двоичной трансляции
Рассмотрим несколько существующих на сегодняшний день систем двоичной трансляции. Система "FXJ32" создавалась фирмой Digital Equipment Corporation для обеспечения возможности исполнения приложений платформы Windows NT/i386 на платформе Windows NT/Alpha, поддерживавшейся в то время фирмой Microsoft. Таким образом, работа по реализации транслятора на уровне приложений была значительно облегчена за счет использования родственной исходной целевой ОС. Однако, разработчикам не удалось избежать привязки транслятора к конкретным версиям целевой ОС, поскольку в процессе своей работы FXI32 приходится корректировать некоторые связанные с задачами структуры данных, рассматривавшиеся Microsoft как недокументированные свойства ОС и потому менявшиеся от версии к версии. Основными целями разработки являлись обеспечение прозрачности исполнения и сравнимые результаты по производительности на уровне верхних моделей микропроцессоров обеих архитектур (Alpha 21164 500 МГц и Intel Pentium Pro 200 МГц соответственно).
Показательно, что разработчики FXI32 отмечают в качестве недостатка динамической оптимизирующей схемы необходимость баланса между временем трансляции и собственно исполнения двоично-транслированного кода для сохранения интерактивности исполняемой задачи, и как следствие - ограниченность набора применяемых оптимизаций кода. Однако, этот вывод приводит к несколько ущербному решению - отказаться от использования динамической схемы вообще и применять на первом проходе чистую интерпретацию с получением профильной информации для последующей фоновой статической оптимизирующей трансляции приложения, с сохранением результата трансляции в базе данных оптимизированных кодов. В итоге, судя по многочисленным нареканиям именно на скорость "первого прохода", реализованная схема интерпретации так и не смогла достигнуть приемлемой производительности, даже со скидкой на упреждающее информирование пользователей о замедлении исполнения на первом запуске. А ведь вполне возможно, что применение быстрого, неоптимизирующего двоичного транслятора на первой фазе смогло бы значительно смягчить падение производительности по сравнению с оптимизированным вариантом.
В процессе прогона приложения, интерпретатор FXI32 накапливает профильную информацию о задаче запоминая, в частности, цели процедурных и дуги косвенных переходов. По завершении исполнения приложения, менеджер FXI32 сохраняет полученную информацию в базе данных и сравнивает текущую с ранее наличествовавшей, выявляя необходимость в запуске оптимизирующего транслятора по обнаружению нового кода в приложении. Подлежащие пере- либо первичной трансляции задачи ставятся в очередь, обрабатываемую в моменты простоя машины (критерий простоя специфицируется пользователем системы).
При трансляции, оптимизирующий транслятор FX132 руководствуется собранной профильной информацией для разбиения исходного кода на единицы трансляции, приблизительно отвечающие процедурам исходного кода. Такое расширение рамок оптимизаций от единичного линейного участка до их набора позволяет при- менять в процессе работы транслятора множество глобальных оптимизаций, давно и непременно используемых в оптимизирующих трансляторах с ЯВУ. После разбора исходного кода, построения промежуточного представления и проведения на нем оптимизаций выполняется генерация целевого кода и его сохранение в базу данных. При следующем запуске, в используемую интерпретатором таблицу накопления адресов целей процедурных переходов заносятся из базы данных указания о том, какие из наличествующих в задаче процедур уже были транслированы в код целевой платформы и могут быть использованы непосредственно - в результате, при попытке передачи управления на этот адрес интерпретатор запустит на исполнение уже оптимизированный код для этой процедуры.
Анализируя успешность достижения поставленных разработчиками целей, нельзя не отметить что хотя задача достижения производительности сравнимой с исполнением исходных кодов на исходной платформе одного на то время уровня с целевой платформой и была достигнута, но прямая перекомпиляция например Byte Benchmark оптимизирующим компилятором целевой платформы позволяла достичь в два раза больших цифр производительности [12] - что явно свидетельствует о недостаточной эффективности используемой схемы двоичной трансляции и слабой оптимизации получаемого двоично-транслированного кода. По свидетельству разработчиков [13], в большинстве случаев производительность приложений на втором запуске под FXI32 на 500МГц Alpha 21164 находилась между Intel Pentium и Intel Pentium Pro на 200МГц, хотя можно отметить что задачи с плавающей арифметикой показывают худшие результаты нежели целочисленные задачи. Приводимые цифры по тестовому набору ВарСо SysMark 32 свидетельствуют о получении 30 процентного ускорения в среднем на 500МГц Alpha по сравнению с 200МГц Pentium, хотя картина и не является однородной - подтест Corel Draw ускоряется на 70 процентов, в то время как подтест Paradox замедляется на 30.
Задача же прозрачности функционирования была решена достаточно успешно, чего нельзя сказать об универсальности получившегося решения - FXI32 не поддерживает часть интерфейсов API Win32 (к примеру, отладочные возможности), не обеспечивает трансляцию драйверов (что было бы крайне кстати для платформы Windows NT/Alpha) и ввиду необходимости перекодировки параметров на вызовах между исходным и целевым кодами в обе стороны, может обеспечивать совместное использование этих кодов только для известного ему подмножества таких межмодульных вызовов.
Особенности двоично-транслирующей системы "Lintel"
Основной чертой, отличающей Lintel от большинства существующих двоично-транслирующих систем, можно считать тесную взаимосвязь с аппаратурой целевой платформы, вобравшей в себя множество механизмов аппаратной поддержки двоичной трансляции. В отличие от систем, создававшихся с целью функционирования на уже законченных дизайнах аппаратуры (FXI32, WABI, и т.д.) и вынужденных адаптироваться к принятым без оглядки на возможные последствия для двоично-транслирующих систем решениям, рассматриваемая двоично-транслирующая система с самого начала являлась неотъемлемой компонентой архитектуры "ЭЗМ" и оказывала непосредственное влияние на процесс разработки аппаратуры платформы, закладывая необходимые для ее эффективного функционирования механизмы в аппаратуру ВК "ЭЗМ".
К механизмам и решениям, реализованным в аппаратуре ВК "ЭЗМ" и оказывающим значительной воздействие на функционирование комплекса в режиме двоичной совместимости под управлением Lintel, можно отнести:
Совместимые типы данных и семантические примитивы — для эффективного отображения семантики исходной платформы микропроцессор "ЭЗМ" поддерживает работу со всеми входящими в описание IA-32 типами данных и включает операции выработки флагов, формирования предикатов на базе стандартно используемых комбинаций флагов, 80-разрядную арифметику с плавающей точкой и выработкой плавающих флагов, ММХ-, SSE- и SSE2-совместимые примитивы.
Организация регистрового файла — регистровый файл микропроцессора "ЭЗМ" разделен на рабочую область, доступную локально в контексте исполняемой в данный момент процедуры а также в качестве области передачи параметров, и глобальную область, идентично видимую из контекста любой процедуры. Это позволяет эффективно хранить на глобальных регистрах текущее архитектурное состояние исходной платформы, гарантируя его доступность в любой момент времени из любой точки ДТС, и в то же время обеспечивать двоично-транслированные коды и процедуры ДТС необходимым количеством рабочих регистров. Кроме этого, в глобальных регистрах выделена специальная секция с правилами доступа, позволяющими эффективно эмулировать работу с регистрами FPU-стека в архитектуре IA-32.
Разделение виртуальных пространств — в архитектуре "ЭЗМ" процессор оперирует двумя наборами виртуальных пространств, первичным и вторичным. Первичное виртуальное пространство может содержать исполняемые коды и используется при работе в режиме двоичной совместимости для хранения самой двоично-транслирующей системы и двоично-транслированных кодов, вторичное же пространство содержит только данные и используется для хранения виртуального пространства исходной платформы, идентично повторяя виртуальное пространство IA-32. Наборы виртуальных пространств независимы с точки зрения архитектуры "ЭЗМ", для них определены различные свойства, правила доступа, методы трансляции математического адреси операции обращения в память [56]. Такая организация позволяет повысить эффективность работы системы за счет аппаратной реализации соответствующих исходной платформе свойств вторичного пространства, благодаря чему отсутствует необходимость во вмешательстве в управление памятью, проводимое ОС исходной платформы, и в то же время не накладывает никаких ограничений на проводимое ДТС управление памятью в первичном пространстве.
Механизм обнаружения обращений в области памяти, отображенные на внешние устройства — обращения в области памяти, отображенные на внешние устройства, должны исключаться из оптимизационных преобразований из-за возможных побочных эффектов выполнения этих операций. Аппаратная поддержка позволяет обеспечивать динамическое обнаружение таких обращений и информировать об этом системную поддержку без каких-либо специальных действий в двоично-транслированном коде, снижающих его эффективность.
Поддержание когерентности двоично-транслированных кодов — двоично-транслирующая система должна поддерживать когерентность ранее транслированных и осевших в кэше трансляций находящимся в данный момент по соответствующим адресам памяти исходным кодам. Аппаратурой реализуется механизм защиты от модификаций памяти, порождающий особую исключительную ситуацию при попытке записи в область памяти, содержащую ранее транслированный код исходной платформы. Обрабатывая ситуацию, системная поддержка находит более недействительные трансляции и удаляет их из кэша и ТПА. Активная работа этого механизма приводит к потерям в эффективности работы системы, особенно для приложений со смешением кода и данных в пределах одной 4К-страницы2, но является необходимым условием надежной работы системы ДТС.
Табличный кэш — внутрикристалльная ассоциативная память небольшого По соображениям аппаратной реализации схема работает с загрублением в 4К. объема. Позволяет повысить эффективность работы ДТС за счет кэширования части ТПА в аппаратуре.
Механизм поддержки точного прерывания — для реализации модели точного прерывания в оптимизированном коде с минимальными ограничениями на проводимые оптимизации применяется методика точки восстановления. В оптимизированном регионе размещаются множество точек восстановления, а дополнительно к коду региона транслятор также создает набор т.н. компенсирующих кодов, позволяющих покинуть регион с корректным восстановлением контекста исходной платформы и продолжить исполнение в неоптимизированном режиме. При возникновении исключительной ситуации, системная поддержка выполняет поиск соответствующего последней успешно пройденной точке восстановления компенсирующего кода, и запускает его на исполнение, обеспечивая таким образом откат к этой точке.
Механизм отложенного прерывания — позволяет повысить эффективность работы двоично-транслированных кодов и действий системной поддержки по доставке внешних прерываний за счет явного выделения мест приема прерываний. По приходу прерывания, системная поддержка просто запоминает этот факт и возвращает управление исполняемому коду. Двоичный транслятор же расставляет в двоично-транслированных кодах команды проверки наличия такого отложенного прерывания в удобных ему местах, что позволяет не накладывать ограничений на планирование прочих участков кода из предположения о возможном приходе прерывания в неопределенный момент времени и необходимости предоставления системной поддержке достаточной информации для корректного прерывания исполнения текущего кода и перехода к доставке прерывания.
Построение адаптивной двоично-транслирующей системы
Вначале, определим методы и схему построения адаптивной динамической ДТС (АДДТС) в общем виде. Затем, перейдем к более обстоятельному рассмотрению специфики предлагаемой схемы.
Введем в состав АДДТС поддержку компонент с различной эффективностью исполнения кода исходной платформы. В общем случае можно говорить о включении в состав АДДТС интерпретатора, шаблонного транслятора и набора оптимизирующих трансляторов различных уровней оптимизации, где повышение затрат на функционирование и эффективности исполнения кода исходной платформы соответствует ряду интерпретатор — шаблонный —у
Обеспечим поддержку различных методов формирования единицы обработки кода исходной платформы. В зависимости от типа исполняющей компоненты, ей могут быть доступны различные формы единиц обработки кода исходной платформы. Так, интерпретатор будет функционировать на покомандной основе, шаблонный транслятор может оперировать в терминах линейных участков, а возможно и более сложных образований - регионов произвольной конфигурации или линейных трасс как их простейшего проявления, которые также будем рассматривать в роли единиц оптимизирующей трансляции. Для регионов также учтем наличие различных методов их образования, включая как сам принцип формирования, так и ограничители на размер единицы трансляции. Под "уровнем оптимизации" здесь и далее будем понимать совокупную эффективность исполнения, включающую в себя как степень оптимизации кода так и качество единицы обработки кода - к примеру, шаблонную трансляцию трассы будем считать повышением уровня оптимизации по сравнению с шаблонной трансляцией линейного участка.
Будем опираться на действительный характер работы кодов исходной платформы для оценки требуемой эффективности их исполнения. Введем в АДДТС подсистему профилирования, и определим ориентацию на смену уровня оптимизации того либо иного участка кодов исходной платформы в результате динамического анализа собираемой профилированием информации. Помимо принятия решения об изменении уровня оптимизации, такая информация естественно должна поступать и в сам процесс трансляции очередного уровня, если он способен задействовать ее для повышения эффективности создаваемого кода. Различные уровни оптимизации могут реализовывать различные схемы профилирования, зависящие от положения текущего уровня в иерархии степеней оптимизации и потребностей следующего уровня.
Реализуем инфраструктуру обратных связей в АДДТС. Непрерывно анализируя информацию о поведении АДДТС, будем динамически вносить коррективы в характер и методы ее функционирования. На основании полученных сведений будем уменьшать уровень оптимизации трансляции в случае падения эффективности ее исполнения, менять условия выхода на новые уровни оптимизаций и вносить коррективы в прочие динамически определяемые аспекты функционирования АДДТС.
Функционирование такой АДДТС протекает в соответствии со следующими схемами. Основной поток исполнения: 1. Управление исходной платформы переходит на очередной адрес исходной платформы. 2. Анализируя профильную информацию, определяем необходимость перехода к шагу 5 для изменения уровня оптимизации исполняемого кода до Onew. Первое исполнение кода можно считать переходом к уровню оптимизации 3. Исполняем код исходной платформы на текущем для него уровне оптимизаций Ocur, обновляя профильную информацию в процессе исполнения. 4. Возвращаемся к шагу 1. 5. Подготавливаем необходимые условия для исполнения кода на новом уровне оптимизации Onew, включая формирование единицы трансляции и собственно процесс трансляции для не-интерпретирующего исполнения. Планируем и реализуем механизмы профилирования для уровня Опеш. 6. Полагая теперь для рассматриваемого кода Ocur:=Oneu,, переходим к шагу 3. Поток обратных связей: 1. Функционирование АДДТС в целом порождает множество макрособытий, таких как создание и удаление трансляций, заполненность кэшей трансляций, и пр.. 2. Такие макрособытия регистрируются в глобальных счетчиках системы и используются для определения общих для множества трансляций условий -коэффициенты при рассчете пограничного значения смены уровня оптимизации, и т.д.. 3. Исполнение каждой отдельной трансляции порождает множество микрособытий, подобных откатам из оптимизированного кода. 4. Такие микрособытия регистрируются локально по отношению к каждой трансляции и позволяют выполнять коррекцию свойств любой из трансляций на индивидуальной основе. 5. Собираемая информация позволяет динамически влиять на принимаемые на шагах 2 и 5 основного потока решения, обеспечивая постоянную подстройку поведения АДДТС под текущий характер исполнения кодов исходной платформы.
Детали построения конкретной ДТС, соответствующей приведенной схеме, в значительной степени зависят от особенностей ее реализации и свойств целевой платформы. В то же время, можно привести набор рекомендаций по принятию решений в процессе такого построения.
Определим метод подсчета порогового значения счетчика исполнений повышения уровня оптимизации в АДДТС. Принимая искомое значение за R, будем вычислять его по формуле где Т - время исполнения трансляции на текущем уровне оптимизации, К - коэф-. фициент ускорения исполнения трансляции при переходе на следующий уровень оптимизации, О - временные затраты на получение трансляции на следующем уровне оптимизации, г Z - динамически определяемый демпфирующий коэффициент. Отметим, что при продолжении работы профилирования на следующем уровне оптимизаций в О включается также и работа по подготовке соответствующих механизмов профилирования, а К должен учитывать вносимое этими механизмами возмущение в скорость исполнения кода.
Коэффициент Z используется для динамической адаптации порогового значения к характеру исполнения кодов исходной платформы. Значение коэффициента автоматически повышается системой при росте числа неэффективных трансляций следующего уровня, то есть трансляций, исполнявшихся слишком малое число раз для того, чтобы компенсировать затраты на повышение уровня оптимизаций, в результате чего снижается агрессивность системы по переводу трансляций на этот следующий уровень. При росте же числа эффективных трансляций, успевших окупить повышение своего уровня оптимизации, система наоборот снижает значение этого коэффициента, обеспечивая более агрессивный подход к переводу трансляций на этот уровень.
Поскольку задачи оптимизации, решаемые различными уровнями в АДДТС, вообще говоря, различны, то и методы профилирования исполнения, используемые при смене уровня оптимизации, могут отличаться от уровня к уровню.
К примеру, при переходе от интерпретации к шаблонной трансляции вполне оправданна простая привязка независимых счетчиков к набору точек входа в код, соответствующих определенным критериям, с последующим съемом линейной трассы исполнения по достижении счетчиком порогового значения, реализованная в частности в Dynamo [20]. Однако, этот метод ограничивает единицу трансляции линейной трассой и в то же время не обеспечивает статистической надежности выборки правильного (то есть, наиболее распространенного) пути.
Хранение двоично-транслированного кода на внешнем носителе
Для решения описанных проблем, автором предлагается еще один метод повышения адаптивности динамической двоично-транслирующей системы, основанный на применении энергонезависимой базы данных [52] для хранения оптимизированных двоично-транслированных регионов (базы кодов, БК). Фактор энергонезависимости является ключевой особенностью предлагаемого метода, ибо он позволяет обеспечить наличие некоторого множества готовых к использованию оптимизированных регионов сразу же после старта машины, в отличие от динамически заполняющихся в процессе работы кэшей трансляций, и позволяет говорить о получении кумулятивного выигрыша от оптимизации двоично-транслированного кода, накапливающегося в процессе эксплуатации ВК, не ограниченном каждым его перезапуском.
В результате, динамическая схема приобретает такое важное достоинство статической схемы, как возможность однократной трансляция участков приложения вне зависимости от числа запусков этого приложения. Однако, в отличие от статической схемы, на длительное хранение будут поступать лишь регионы, частое исполнение которых способно многократно окупить дополнительные затраты времени на оптимизацию (и работу внутренних механизмов БК) благодаря последующему сокращению времени их исполнения. Такой избирательный подход позволяет значительно сэкономить занимаемое трансляциями при хранении место, расходуя его лишь под действительно важные с точки зрения производительности участки кода.
В многоуровневой схеме построения АДДТС, добавление БК позволяет длительно хранить в ней коды высших уровней оптимизации, обеспечивая возможность ускоренного перехода к исполнению этих кодов, минуя несколько стадий повышения уровня оптимизации. Таким образом, обеспечивается новый уровень адаптации динамической ДТС к поведению кодов исходной платформы, позволяющий расширить рамки наблюдения за характером исполнения кодов исходной платформы на ВК за пределы единичного запуска.
Наблюдая за типичным использованием ВК, АДДТС получает возможность прогнозировать возникновение потребностей в исполнении тех или иных кодов в дальнейшем и помещать их в БК для долговременного хранения. Наблюдая же в будущем тенденцию, способную привести к востребованию ранее полученных регионов, АДДТС может спекулятивно поднять их высокооптимизированные версии из БК, тем самым значительно ускорив переход к исполнению оптимизированных кодов.
В случае же возможной ошибки такого спекулятивного подъема, обратные связи позволяет АДДТС вовремя обнаружить несоответствие между поднятыми регионами и актуальным в данный момент поведением системы, инициируют необходимые действия по перетрансляции соответствующих участков исходного кода и обновят сопроводительную статистическую информацию в БК, предписывая АДДТС в дальнейшем выполнять более консервативную оценку целесообразности спекулятивного подъема этих регионов.
Хочется отметить, что благодаря использованию БК затраченное на оптимизацию двоично-транслированных кодов время может быть компенсировано не немедленно, но на следующих запусках оптимизированного кода, как в том же сеансе работы, так и после перезапуска ВК.
Важной особенностью метода также является и то, что единицей работы считается в общем случае абстрактный регион, в отличие от целого приложения в виде исполняемого двоичного образа вполне определенной структуры, уникального для целевой ОС, использующегося в статических схемах. Таким образом, метод не привязан к конкретной ОС и не должен уметь распознавать тот либо иной формат приложений в файловой системе либо в памяти, не требует доступа к коду всего приложения, не обязан отслеживать моменты рождения и смерти процессов внутри исходной ОС.
Аппаратная поддержка БК включает в себя заведение в машине дополнительного накопителя, предназначенного для хранения собственно оптимизированных кодов и вспомогательной служебной информации. Ввиду необходимости поддержания целостности хранимой им информации видится целесообразным скрыть его существование от ОС и приложений исходной архитектуры, гарантировав тем самым эксклюзивность доступа к нему со стороны двоично-транслирующей системы. В частности, при превышении разрядностью физического адреса целевой платформы разрядности физического адреса исходной платформы удобно использовать это количественное превосходство в разрядах для сокрытия механизма доступа к обеспечивающей функционирование БК аппаратуре за счет отображения управляющих регистров и окна данных (при работе в режиме программируемого ввода-вывода) по верхним адресам памяти.
С учетом постоянного совершенствования современных технологий хранения информации, наиболее перспективным видится оформить аппаратуру поддержки БК в виде одного из доминирующих на сегодняшний день стандартов дисковых каналов, к примеру АТА, что позволит автоматически переходить на более быстрые, емкие, экономичные в энергопотреблении и экономически оправданные модели накопителей по мере их появления на рынке.
Что же до выбора типа используемого накопителя данных, то здесь наиболее перспективным представляется применение flash-памяти либо иных аналогичных технологий твердотельных накопителей. Основное преимущество накопителей на магнитных дисках - высокая скорость обмена данными - не является столь важным для БК ввиду относительно небольших (по современным масштабам) размеров квантов информации, участвующих в процессах обмена. В то же время, для реализации быстрого поиска по БК крайне важно минимизировать время доступа к этим квантам, что обычно и обеспечивается накопительными устройствами, построенными на базе твердотелых устройств.
Можно отметить, что при отсутствии требования универсальности работы БК в принципе возможно отказаться от заведения дополнительного накопителя в системе и размещать всю информацию непосредственно в файловой системе наперед заданной исходной ОС, реализую защиту и хранение специально для этой цели созданным драйвером под эту ОС, однако в этом случае многократно возрастает угроза повреждения хранимых трансляций в результате ошибки оператора либо действий вредоносного или некорректного программного обеспечения, что приведет к необходимости усиления контроля за целостностью хранимой информации. Кроме того, при обновлении пользователем исходной ОС на новую версию функциональность БК будет с большой долей вероятности деактивироваться до момента обновления двоично-транслирующего программного обеспечения на ВК.
