Влад Борисов
Как стало известно, в конце марта на конференции JavaOne фирма Sun Microsystems представит окончательную версию спецификации EmbeddedJava, появление которой откладывается уже полгода.
При разработке EmbeddedJava Sun столкнулась с двумя основными проблемами: нехваткой памяти и недостаточной производительностью встроенных систем.
Фирме потребовалось сократить громоздкие библиотеки классов так, чтобы все компоненты смогли поместиться в ПЗУ объемом 512 Кб. Для этого специалисты Sun устранили из системного кода ненужные константы и постарались по возможности использовать 16-разрядную арифметику вместо 32-разрядной, что позволило уменьшить размер кода на 20%.
Sun также пришлось поломать голову над тем, как ускорить виртуальную машину Java (JVM), чтобы Java-приложения выполнялись со скоростью, соизмеримой с той, что обеспечивают Си++ и Ассемблер. Однако применить для этого технологию HotSpot, которая анализирует и оптимизирует куски байт-кода Java, не удалось. По словам представителей фирмы, программа HotSpot оказалась слишком объемной и попросту не влезает в 512 Кб.
Решить эту головоломку Sun намечает за счет внедрения оптимизирующих JVM-процессоров для каждой из аппаратных архитектур встроенных систем. Какие из производителей будут выпускать такие процессоры, пока не сообщается. Обозреватели отрасли полагают, что ими станут сама Sun с ее технологией picoJava, а также NEC LG Semicon и Rockwell, которые выпускают picoJava-микросхемы для сетевых компьютеров. Известно также, что Fujitsu и Siemens лицензировали picoJava. Кроме того, стало известно, что Sun работает и над оптимизирующим JVM-процессором для встраиваемых архитектур 68k, PowerPC (Motorola недавно купила лицензию на EmbeddedJava) и x86.
Выходящая в марте EmbeddedJava будет не просто спецификацией, а созданным Sun программным пакетом, поставляемым для производителей ОС реального времени (RTOS). В него войдут JVM и большой набор библиотек классов, обеспечивающих работу в сетях, ввод-вывод и некоторые другие функции. EmbeddedJava лицензировали десять производителей ПО для встраиваемых систем: Acorn, Chorus (принадлежит SunSoft), Geoworks, Lucent Technologies, Microtec Research, Microware Systems, QNX, US Software и Wind River Systems.
Каждый из поставщиков RTOS должен будет создать программный интерфейс между своей ОС и EmbeddedJava, что само по себе непросто. Помимо этого имеется и ряд других проблем.
Так, типичная RTOS используется в большом числе разных по возможностям встраиваемых систем. У некоторых из них могут иметься графические подсистемы ввода-вывода и связь с сетью, а у других - нет. Третьи системы должны работать с минимальным объемом ОЗУ.
Поэтому Sun и производители RTOS вынуждены создавать ПО, которое работает на неопределенно большом числе платформ. Между тем 512 Кб - это объем лишь кода базовых классов Java. С учетом же “родного” кода, связывающего JVM и RTOS, запросы к памяти у EmbeddedJava могут заметно вырасти.
В связи с этим Sun пытается убрать из своих программ все лишнее. Часть библиотек классов она определила как заменяемые и необязательные. Например, поставщик RTOS может не использовать графическую библиотеку AWT. Однако если во встраиваемой системе имеется LCD-дисплей, то задача обеспечения работы с графикой ложится именно на него.
Немалые проблемы может вызвать и механизм “сборки мусора”: когда он начинает работу, то серьезно загружает процессор. Специалисты Sun пытаются решить эту проблему, сделав “сборку мусора” регулярным процессом, отнимающим у ЦП не более нескольких миллисекунд в секунду.
То, насколько это удалось, можно будет узнать лишь после появления первых устройств на базе EmbeddedJava.
