ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2017 г.)
2-летний импакт-фактор РИНЦ: 0,500
2-летний импакт-фактор РИНЦ без самоцитирования: 0,405
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,817
5-летний импакт-фактор РИНЦ: 0,319
5-летний импакт-фактор РИНЦ без самоцитирования: 0,264
Суммарное число цитирований журнала в РИНЦ: 6012
Пятилетний индекс Херфиндаля по цитирующим журналам: 404
Индекс Херфиндаля по организациям авторов: 338
Десятилетний индекс Хирша: 17
Место в общем рейтинге SCIENCE INDEX за 2017 год: 527
Место в рейтинге SCIENCE INDEX за 2017 год по тематике "Автоматика. Вычислительная техника": 16

Больше данных по публикационной активности нашего журнале за 2008-2017 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2018

Исследование Java-виртуальной машины реального времени

Статья опубликована в выпуске журнала № 4 за 2000 год.[ 23.12.2000 ]
Аннотация:
Abstract:
Авторы: Сидельников В.В. () - , ,
Ключевое слово:
Ключевое слово:
Количество просмотров: 7720
Версия для печати
Выпуск в формате PDF (1.83Мб)

Размер шрифта:       Шрифт:

На протяжении последних 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.

Подпись:  
Рис. 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.

Подпись:  
Рис. 2

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

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

Подпись:  
Рис. 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


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=908
Версия для печати
Выпуск в формате PDF (1.83Мб)
Статья опубликована в выпуске журнала № 4 за 2000 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: