Программные продукты и системы

На протяжении последних 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 Kб. Данное требование вызвано необходимостью рассмотрения возможностей Java-машины применительно ко встроенным СРВ.

Архитектура рассматриваемой в работе виртуальной машины представлена на рисунке 1.

Обеспечение предсказуемости при выполнении приложения реального времени имеет наивысший приоритет при решении любых компромиссов в реализации виртуальной машины, и для достижения необходимого детерминизма требуется обеспечить следующие условия: строго приоритетное выполнение ниток реального времени; приоритетное обслуживание очередей мониторов; обход инверсии приоритетов; детерминизм в работе сборщика мусора.

Реализация перечисленных условий в первую очередь затрагивает подсистемы управления памятью и сборки мусора, управления нитками и диспетчеризации и тесно связанную с ней подсистему обработки событий. Поэтому основное внимание уделяется организации именно этих компонентов.

Представленная архитектура была реализована для работы на двух платформах – Win32 и на симуляторе SingleStep (фирма Diab Data) процессора M*Core производства фирмы Motorola. При этом обеспечивалась минимальная зависимость виртуальной машины от операционной среды, которая предоставляла только таймерные события.

Наибольшим препятствием в реализации виртуальной машины реального времени является сборка мусора. В условиях ограничения на размер памяти, упомянутого выше, целесообразным представляется использование компактирующих алгоритмов [5,6], которые позволяют избежать фрагментации. Накладные расходы на перемещение объектов в данном случае будут весьма невелики вследствие небольших размеров кучи (в нашем случае использовалась куча размером 64-256 Kб). Таким образом, исследовалось несколько mark-compact алгоритмов как в режиме stop-and-collect, так и в инкрементальном режиме. В первом случае сборщик мусора активизируется при заполнении кучи и работает в монопольном режиме. В инкрементальном режиме сборка мусора может прерываться; она выполняется с вытеснением более приоритетными действиями. Вследствие того что коллектор в stop-and-collect режиме не может прерываться, задержка реакции на асинхронное событие (latency) при некоторых условиях может быть весьма велика. Однако в экспериментах при размере кучи 64 Kб на процессоре с тактовой частотой 50 MГц максимальное значение latency не превышало 70 мс, что является приемлемым для широкого класса интерактивных приложений.

Сравнительные результаты экспериментов с инкрементальными и stop-and-collect коллекторами, полученные при размере кучи 256 Кб, представлены на рисунке 2.

По оси абсцисс откладывается доля событий, начало обработки которых задерживалось на время, не превышающее значение, представленное по оси ординат. Значение latency измерялось в циклах процессора M*Core. В данном случае результаты со stop-and-collect коллектором ухудшаются примерно вдвое относительно варианта с кучей, размер которой 64 Кб. Однако использование инкрементального режима сборки мусора дает значительные улучшения. При пересчете значений задержки в единицы времени максимальная величина latency, полученная с инкрементальным коллектором на процессоре с тактовой частотой 50 МГц, не превышает 0.2 мс, что уже могло бы быть приемлемым не только для интерактивных приложений, но и для систем управления оборудованием.

Подсистема управления ниткам может быть реализована двумя принципиально различными способами. Первый основан на том, что виртуальная машина работает под управлением некоторого ядра реального времени и использует механизмы диспетчеризации этого ядра. В этом случае при создании нитки реального времени создается задача ядра, связанная с объектом класса RealtimeThread. Наряду с определенным упрощением подсистемы управления нитками в самой виртуальной машине возникают определенные проблемы при переключении контекста. Очевидно, что ядро может осуществлять переключение с одной нитки на другую в процессе выполнения интерпретатором некоторого байт-кода, что вызывает необходимость запоминать контекст машины и фактически создавать экземпляр интерпретатора для каждой нитки. Такой подход позволяет снизить latency, однако требует повторной входимости интерпретатора. Второй подход подразумевает реализацию управления нитками целиком внутри машины. В этом случае нет необходимости прерывать выполнение байт-кода, что существенно снижает зависимость машины от особенностей ядра операционной системы, однако приводит к увеличению latency. Рассматриваемая виртуальная машина реализована в соответствии со вторым вариантом, и процедура диспетчеризации с поддержкой протокола наследования приоритетов выполнена целиком в рамках подсистемы управления нитками и диспетчеризации. Схема распределения приоритетов представлена на рисунке 3.

K наивысших приоритетов (в соответствии с [1] K=27) отводятся под нитки реального времени, диспетчеризация которых осуществляется с вытеснением исполняемой нитки ниткой реального времени с более высоким приоритетом. При использовании stop-and-collect сборки мусора коллектор имеет наивысший приоритет и вытесняет любую нитку. Приоритет инкрементального коллектора (если используется коллектор этого типа) назначается ниже последнего приоритета реального времени. Нитки "не реального времени" занимают последний приоритет реального времени и располагаются в очереди готовых согласно их приоритетам "не реального времени". Диспетчеризация ниток "не реального времени" осуществляется в соответствии с time-slicing, что обеспечивает невозможность их блокировки (естественно, при сбалансированной общей производительности системы).

Эксперименты с рассматриваемой виртуальной машиной показали, что время реакции системы порядка долей миллисекунды, а обеспечение предсказуемости работы приложения реального времени являются вполне достижимой целью. Реализованная машина не является конечным продуктом и может быть существенно оптимизирована, что позволит улучшить ее характеристики. Конечно, можно было бы отметить ряд спорных моментов, например, необходимость аккуратного использования native-методов, прерывание которых может вызвать серьезные трудности (с другой стороны, вполне естественным представляется создание native-кода максимально коротким при построении приложений реального времени).

Проведенные эксперименты показывают, что Java-технология является вполне реализуемой применительно к СРВ. Работа в этом направлении может предоставить разработчикам конструктивные способы формализации создания мобильных программ реального времени и существенно поднять уровень средств разработки программного обеспечения СРВ, что, в свою очередь, позволило бы значительно расширить круг потенциальных разработчиков систем такого класса.

Список литературы

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