CC BY
57
ИССЛЕДОВАНИЕ JAVA-ВИРТУАЛЬНОЙ МАШИНЫ РЕАЛЬНОГО ВРЕМЕНИ
В.В. Сидельников
На протяжении последних 25-30 лет было сделано несколько значительных попыток создания языков высокого уровня, которые могли бы составить основу технологии проектирования встроенных систем и систем реального времени (СРВ). Однако, несмотря на огромные достоинства создаваемых средств (достаточно вспомнить, например, Modula-2 или Ada), эти попытки не нашли основополагающего применения в указанном секторе программного обеспечения. В значительной степени это можно отнести на недостаточную их «раскрутку» в условиях конъюнктуры рынка программных продуктов. Другой и, по-видимому, наиболее существенной причиной является слабая переносимость программ, созданных на их основе.
Начиная с 1995 г., фирма Sun Microsystems активно продвигает Java-технологию, обещающую высокую мобильность (write once, run anywhere - написано однажды, исполняется везде), продуктивность, надежность и безопасность создаваемого кода. При создании Java (собственно языка Java, байткод-ком-пиляторов, виртуальной машины, JIT-компиляторов) разработчики не ставили своей целью их применения в условиях ограничений реального времени. Однако целый ряд несомненных достоинств побудил специалистов рассмотреть возможности расширения Java, которые позволили использовать эти средства в проектировании и программировании СРВ. Основные усилия в этом направлении были сделаны двумя рабочими группами - Real-Time Java Expert Group (RTJEG) и jConsortium. Первая группа включала в себя специалистов из 7 ведущих компаний США и работала под идеологическим управлением Sun Microsystems. Идеологом второй группы была компания NewMonics Inc., являющаяся разработчиком компонентов Java-технологии для СРВ и предлагающая их на рынке программных продуктов в настоящее время. Результатом деятельности указанных групп явились два варианта спецификаций, расширяющих Java для использования в СРВ [1,2].
В основе спецификации RTJEG была положена концепция, состоящая в том, что, во-первых, недопустимо изменять семантику языка Java [3] и, во-вторых, предлагаемые расширения на должны быть помехой для исполнения уже существующих Java-приложений. JConsortium, напротив, допускал некоторые изменения семантики и предлагал решения, допускающие несовместимость с уже имеющимися приложениями "не реального времени". При этом как первая, так и вторая спецификации требуют не только разработки API (Application Program Interface) реального времени, но и создания виртуальной машины [4], выполненной в соответствии с их рекомендациями. В первую очередь, такие рекомендации относятся к поддержке ниток реального времени, обра-
ботки асинхронных событий и реализации сборки мусора.
В данной работе излагаются некоторые результаты, полученные в экспериментах с виртуальной машиной, разработанной в соответствии с рекомендациями, сформулированными в [1] и позволяющими оценить возможность использования Java в условиях ограничений реального времени. Для написания тестовых Java-приложений было реализовано подмножество API, специфицированное в [1], включающее в себя следующие классы: RealtimeThread, PeriodicTimer, AsyncEventHandler, RelativeTime, Pri-orityParameters. Дополнительным ограничением являлся допустимый размер памяти, который не должен был превышать 512 Кб. Данное требование вызвано необходимостью рассмотрения возможностей Java-машины применительно ко встроенным СРВ.
Архитектура рассматриваемой в работе виртуальной машины представлена на рисунке 1.
Обеспечение предсказуемости при выполнении приложения реального времени имеет наивысший приоритет при решении любых компромиссов в реализации виртуальной машины, и для достижения необходимого детерминизма требуется обеспечить следующие условия: строго приоритетное выполнение ниток реального времени; приоритетное обслуживание очередей мониторов; обход инверсии приоритетов; детерминизм в работе сборщика мусора.
Реализация перечисленных условий в первую очередь затрагивает подсистемы управления памятью и сборки мусора, управления нитками и диспетчеризации и тесно связанную с ней подсистему обработки событий. Поэтому основное внимание уделяется организации именно этих компонентов.
Представленная архитектура была реализована для работы на двух платформах - Win32 и на симу-ляторе SingleStep (фирма Diab Data) процессора M*Core производства фирмы Motorola. При этом обеспечивалась минимальная зависимость виртуальной машины от операционной среды, которая предоставляла только таймерные события.
Пред. загрузчик
Библиотека классов Классы приложения
Пред. загруженные классы Загрузчик классов Управление памятью и сборка мусора
Динамически загружаемые классы
Интерпретатор
с Активная нитка >
Обработка событий Управление нитками и диспетчеризация
Рис. 1
44
Наибольшим препятствием в реализации виртуальной машины реального времени является сборка мусора. В условиях ограничения на размер памяти, упомянутого выше, целесообразным представляется использование компактирующих алгоритмов [5,6], которые позволяют избежать фрагментации. Накладные расходы на перемещение объектов в данном случае будут весьма невелики вследствие небольших размеров кучи (в нашем случае использовалась куча размером 64-256 K6). Таким образом, исследовалось несколько mark-compact алгоритмов как в режиме stop-and-collect, так и в инкрементальном режиме. В первом случае сборщик мусора активизируется при заполнении кучи и работает в монопольном режиме. В инкрементальном режиме сборка мусора может прерываться; она выполняется с вытеснением более приоритетными действиями. Вследствие того что коллектор в stop-and-collect режиме не может прерываться, задержка реакции на асинхронное событие (latency) при некоторых условиях может быть весьма велика. Однако в экспериментах при размере кучи 64 K6 на процессоре с тактовой частотой 50 M^ максимальное значение latency не превышало 70 мс, что является приемлемым для широкого класса интерактивных приложений.
Сравнительные результаты экспериментов с инкрементальными и stop-and-collect коллекторами, полученные при размере кучи 256 Кб, представлены
По оси абсцисс откладывается доля событий, начало обработки которых задерживалось на время, не превышающее значение, представленное по оси ординат. Значение latency измерялось в циклах процессора M*Core. В данном случае результаты со stop-and-collect коллектором ухудшаются примерно вдвое относительно варианта с кучей, размер которой 64 Кб. Однако использование инкрементального режима сборки мусора дает значительные улучшения. При пересчете значений задержки в единицы времени максимальная величина latency, полученная с инкрементальным коллектором на процессоре с тактовой частотой 50 МГц, не превышает 0.2 мс, что уже могло бы быть приемлемым не только для интерактивных приложений, но и для систем управления оборудованием.
Подсистема управления ниткам может быть реализована двумя принципиально различными способами. Первый основан на том, что виртуальная машина работает под управлением некоторого ядра реального времени и использует механизмы диспетче-
ризации этого ядра. В этом случае при создании нитки реального времени создается задача ядра, связанная с объектом класса RealtimeThread. Наряду с определенным упрощением подсистемы управления нитками в самой виртуальной машине возникают определенные проблемы при переключении контекста. Очевидно, что ядро может осуществлять переключение с одной нитки на другую в процессе выполнения интерпретатором некоторого байт-кода, что вызывает необходимость запоминать контекст машины и фактически создавать экземпляр интерпретатора для каждой нитки. Такой подход позволяет снизить latency, однако требует повторной входи-мости интерпретатора. Второй подход подразумевает реализацию управления нитками целиком внутри машины. В этом случае нет необходимости прерывать выполнение байт-кода, что существенно снижает зависимость машины от особенностей ядра операционной системы, однако приводит к увеличению latency. Рассматриваемая виртуальная машина реализована в соответствии со вторым вариантом, и процедура диспетчеризации с поддержкой протокола наследования приоритетов выполнена целиком в рамках подсистемы управления нитками и диспетчеризации. Схема распределения приоритетов представлена на рисунке 3.
K наивысших приоритетов (в соответствии с [1] K=27) отводятся под нитки реального времени, диспетчеризация которых осуществляется с вытеснением исполняемой нитки ниткой реального времени с более высоким приоритетом. При использовании stop-and-collect сборки мусора коллектор имеет наивысший приоритет и вытесняет любую нитку. Приоритет инкрементального коллектора (если используется коллектор этого типа) назначается ниже последнего приоритета реального времени. Нитки "не реального времени" занимают последний приоритет реального времени и располагаются в очереди готовых согласно их приоритетам "не реального времени". Диспетчеризация ниток "не реального времени" осуществляется в соответствии с time-slicing, что обеспечивает невозможность их блокировки (естественно, при сбалансированной общей производительности системы).
Эксперименты с рассматриваемой виртуальной машиной показали, что время реакции системы по-
на рисунке 2.
latency (ивы MOe)
1169210 1337549 1317440
Bstcp-ankdlect mark-compact ■ ¡ncremeta mark-compac
545 567 583 700
99% 999%
Рис. 2
Приоритеты реального времени
Сборка мусора Stop-and-collect»
Нитки реального времени
Строго приоритетное диспетчированиес вытеснением
Инкрементальная сборка мусора
Приоритеты «не реального времени»
Нитки «не реального времени»
Time-slicing в соответствии с приоритетами «не реального времени»
Рис. 3
K-i
K
N
45
рядка долей миллисекунды, а обеспечение предсказуемости работы приложения реального времени являются вполне достижимой целью. Реализованная машина не является конечным продуктом и может быть существенно оптимизирована, что позволит улучшить ее характеристики. Конечно, можно было бы отметить ряд спорных моментов, например, необходимость аккуратного использования па!1уе-методов, прерывание которых может вызвать серьезные трудности (с другой стороны, вполне естественным представляется создание пайув-кода максимально коротким при построении приложений реального времени).
Проведенные эксперименты показывают, что /ауа-технология является вполне реализуемой применительно к СРВ. Работа в этом направлении может предоставить разработчикам конструктивные спосо-
бы формализации создания мобильных программ реального времени и существенно поднять уровень средств разработки программного обеспечения СРВ, что, в свою очередь, позволило бы значительно расширить круг потенциальных разработчиков систем такого класса.
Список литературы
1. The Real-Time Specification for Java. Preliminary release, 2000, http://www.rtj.org.
2. Real-Time Core Extensions for the Java Platform, 2000, http://www.j-consortium.org/rtwg/s1.pdf.
3. The Java Language Specification, by James Gosling, Bill Joy, and Guy Steele, 1996, http://java.sun.com/docs/books/jls/index.html.
4. The Java Virtual Machine Specification, 1996, http://java.sun.com/docs/vmspec/index.html.
5. Uniprocessor Garbage Collection Techniques, by Wilson P.R., 1997 ftp.cs.utexas.edu/pub/garbage/bigsurv.ps.
6. R.Jones and R.Lins, Garbage collection, John Wiley&Sons,
1996.
КОМПОНЕНТЫ ПРОГРАММНОГО КОМПЛЕКСА ПОДДЕРЖКИ СОПРЯЖЕННОГО ПРОЕКТИРОВАНИЯ АППАРАТНО-ПРОГРАММНЫХ СИСТЕМ
А.Х. Мурсаев, В.В. Бакалов
Многие области применения компьютеров, такие как обработка сигналов, изображений, реалистическая графика, телекоммуникации и др., требуют многократного исполнения сравнительно простых операций. В рассматриваемых приложениях значительного повышения производительности системы можно достичь, возлагая подобные операции на блоки специализированного назначения, подключаемые к компьютеру в сопроцессорной конфигурации или в качестве автономного зависимого процессора.
Выбор подмножества процедур, которые целесообразно реализовать аппаратно, и способов их реализации не является однозначным. Существует определенный баланс между функциями, которые более эффективно выполняются в специализированных средствах, и теми, которые выгоднее выполнять (или вынужденно будут исполняться) в центральном процессоре системы. Для его достижения требуется использование унифицированного подхода к разработке аппаратно-программных систем, динамично учитывающего свойства реализуемого алгоритма, возможности и ограничения аппаратных средств. Такой подход называют сопряженным проектированием [1-5]. Основа методологии сопряженного проектирования - параллельная, взаимосвязанная проработка программных и аппаратных средств, которая позволяет добиваться качественных показателей проекта и снижения сроков проектирования.
В настоящей статье излагается структура системы поддержки сопряженного проектирования и представляются ее основные программные модули.
Структура системы сопряженного проектирования и общие требования к ее компонентам.
Концепция сопряженного проектирования предполагает решение следующих взаимосвязанных вопросов.
• Анализ задачи и разделение ее решения на фрагменты, безусловно назначаемые к исполнению программно, безусловно исполняемые в аппаратуре, и фрагменты, которые могут быть назначены как в аппаратную, так и в программную части таким образом, чтобы максимизировать показатель качества системы в целом в зависимости от имеющихся ресурсов.
• Создание библиотек возможных исполнителей алгоритмов, типичных для предполагаемых областей применения. Каждый объект такой библиотеки представляет некоторую задачу и включает несколько вариантов программной реализации, например в форме С++-кодов, а также несколько вариантов реализующих структур, например представляемых как описания на языках схемотехнического проектирования типа УЫБЬ. Эти варианты сопровождаются количественными характеристиками возможных исполнителей, такими как время исполнения, затраты памяти, используемые ресурсы микросхем программируемой логики.
• Выбор оптимального сочетания исполнителей частей задачи исходя из определенной целевой функции, ограничений и характеристик задачи.
• Разработка соответствующего интерфейса между процессором общего назначения и специализированным модулем, как и между блоками, включаемыми в аппаратную часть системы. При этом следует обращать внимание на проблемы согласованности форматов данных, буферизацию, взаимное оповещение и взаимное блокирование процессов.
46
