Средства и методы разработки

Embedded Real-Time Java: Интересно, почему оно так медленно внедряется? Но, тем не менее, создатели PhantomOS, похоже, совсем не идиоты. Операционная система «Фантом» http://dz.ru/solutions/phantom/ У джабы есть интересное расширение - RTSJ. The RTSJ is the specification resulting from JSR-1, the first specification launched through the Java® Community Process. The specification was approved in January 2002. The first commercial implementation followed in Spring of 2003. The second release of the reference implementation(RI) was in Spring 2004, and version 1.0.1 of the RTSJ was released (with updates to the RI and Technology Compatibility Suite) in June 2005. http://www.rtsj.org  thread scheduling,  memory management,  synchronization,  asynchronous events,  asynchronous flow of control,  thread termination, and  physical memory access. В основе лежит правильная идея - оно никак не расширяет байткод и программа с RTSJ (который суть набор классов) компилится обычным джаба-компилером. А вот VM должна специально обрабатывать объекты особого базового класса. Красота самой джабы понятна, но вопрос в том, как реально все это исполнять в embeddeed железе. Я так понимаю, что есть 3 стратегии: * JVM как интерпретатор - медленно * JVM JIT - так живут все современные быстрые джабы, как я понимаю * JVM с аппаратным ускорением. Для embedded систем по толстым техпроцессам, без гигагерцовых ядер на кристалле, IMHO реален только 3-й путь (JVM в ATmega32 - это круто, но мы говорим про бизнес-решения, а не про игрушки). Оказывается, такие решения есть. Контора, у которой байткод выполняется в специализированном ASIC 0.18. Есть отладочные платы за разумные деьги. Thread-to-thread yield in less than 1μsec @ 160 MHz - не чемпионский результат, но достаточно RT, чтобы не париться по этому поводу. Похоже, у них не совсем честный исполнитель байт-кода, а некий низкоуровневый микрокодный интерпретатор. http://www.ajile.com Внимательное изучение темы аппаратного ускорения показывает, что это крайне интересная область для приложения творческих усилий. Есть лобовые методы, типа ARM Jazelle, но они не так уж и быстро ускоряют. http://en.wikipedia.org/wiki/Jazelle Есть более интересные методы. Которые ориентированы на ускорение двух самых проблемых мест: * работа с памятью как со связанным списком * продвинутая сборка мусора The SHAP bytecode processor has been developed at the VLSI-EDA Chair of the Faculty of Computer Science by Martin Zabel and Thomas Preußer since 2006. SHAP provides an embedded Java platform, which is readily available as a proven synthesizable IP core for implementation on FPGA devices and standard cells. http://shap.inf.tu-dresden.de/?n=0 Увы, не все лежит. Additional sources not yet published may be inquired for research and educational purposes. Please, provide some references to your research and/or educational activities with your request. Всасывает нативный байткод, который при помощи некоего "линкера" конвертится во внутренний формат. В одной из приложенных бумаг описан пример в Spartan3 XC3S1000. 50 Мгц, порядка 6к LE. Дизайн старый и неоптимизированный, но даже он смотрится термипо по бенчмаркам с Pentium 90MHz. CaffeineMark 3.0 Early Results есть для Pentium 90MHz, http://www.benchma …q.ru/cm30/results.html Самое интересное в этом решени - • thread creation / switching in 5 cycles, thread killing in 3 cycles. Вот оно! Такое никакой джазелью не сделать, и оно настоящий RT перфоманс дает. Секция ссылок на редкость полезна! http://shap.inf.tu-dresden.de/?n=3 JOP - Java Optimized Processor http://jopdesign.com/perf.jsp This project explains how a JOP processor can be implemented on a ZTEX USB-FPGA Module 1.11c with Spartan6 LX25 FPGA. Currently only 16MB the DDR RAM (of 64MB) are supported. The FPGA utilization is about 23% which allows to build multiple cores in CMP JOP. http://wiki.ztex.d …php?id=en:projects:jop XC6SLX25-2FTG256C - $34 Digikey, 24051 LE, 52 2KByte Block, 186 IO - это как пример камня, о котором тут говорится. XC6SLX9-2FTG256C - $18 Digikey, 9152 LE, 32 2KByte Block, 186 IO - раз 23%, то сюда точно влезет и немного останется. Теперь попробуем понять самую суть. Если мы делаем некое сложное управляющее устройство, в котором есть: * IP - по полной - SSL, IPSEC, SSH и прочая * GSM по полной - MMS, SMS и т.д. * Графика - тоже по полной То выбор у нас небогат. Либо идти по пути Embedded Linux, либо попробовать сходить по пути Java. JIT JVM - это, как правило, одного только кеша на предкомпилированные процедуры 32м. + лялих. И в итоге 1 мкс латентность леакции на событие можно получить только очень извращенными методами типа RTAI. А вот вариант pure Java, как ни странно, очень даже интересен. На управляющих и логических задачах работа с памятью является основным гемороем и тормозом. Программизм распределения памяти, борьба с утечками, затраты проца на реализацию всего этого - вот на это и расходуются все эти гигабайты и гигагерцы. Java изначально построенная на идеологии автоматического управления памятью, и если при программной эмуляции этой радости возникает куча накладных расходов, то при аппаратной поддержке получается резкое ускорение. Поддержка RT на уровне VM тоже сильно помогает оптимизировать процесс. FPGA имеет шанс проявить всю свою мощу. Можно добавить всяких продвинутых менеджеров памяти и проч. Можно добавить DSP блок для ускорения специализированных расчетов. Но, главное показано на вложенной картинке. Java ядра многопоточные, но самих ядер модет быть много! Т.е. пусть у нас достимый перфоманс ядра, 100 Мгц и пусть у него продвинутый менеджер памяти и сборщик мусора. Видимо, на задачах логики и управления можно ожидать перфоманс а ля 100 Мгц ARM7 TDMI (это очень грубая прикидка). В указанный камушек за $34 влазит (очень грубая прикидка) 4 таких ядра. Т.е молучим 400 Мгц ARM. А распараллелить в реально жизни есть что. GUI на одну VM, IP на другу. Ну и придумать механимзм обмена между VM. Одно неприятно - придется с нуля написать много чего на java. А она все-таки сильно отличается от C|C++. По методологии, подходам, инструментарию. Зато точно получится хороший reuse кода. Для того, чтобы можно было начинать экспериментировать: JamaicaVM Personal Edition •Runs OpenJDK 6 Applications •Deterministic Garbage Collection •Implements the Realtime Specification for Java (RTSJ) •Highly optimized for speed with minimal footprint •Available for Linux on x86 •Free for personal use! http://www.aicas.com/jamaica-pe.html