Javolution - Java технология для real-time и safety-critical missions систем

"томми возвращается."

Ну ничего себе. Всегда же говорили "технология java не подходит для рилтаймовых и критических систем и т.д.". Даже EULA к NT4 на этом очень интенсивно внимание акцентировали. А теперь - пытаются и туда протолкнуть.

Им лишь бы рынок заховать, а про последствия даже не думают. Боюсь представить, что будет, если будут софт для ядерных реакторов на джаве писать, а он в тот момент, когда нужно на датчик отреагировать, решит garbage collector'ом по структурам пройтись..

Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

Они ее на шаттлы ставить будут? :D

Ну, например, можно отключить сборщик мусора вообще, но поставить гигантский объём памяти.

Тогда, правда, мы ограничим время непрерывной работы, но многие системы и так регулярно перезагружают по аппаратному таймеру.

> Боюсь представить, что будет, если будут софт для ядерных реакторов на джаве писать

Есть менее ответственные системы, есть soft realtime. Теоретически, с хорошо настроенным сборщиком мусора, Java подходит для soft realtime.

> Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

бесполезно, ты все равно не поймешь - ибо надо по ссылке ходить :-P

>Теоретически, с хорошо настроенным сборщиком мусора, Java подходит для soft realtime.

в Javolution память преаллокируется, так что сборщик почти не нужен

Вроде она на марсоходах стоит, если я ничего не путаю...

Поэтому то с марсом у америкосов облом за обломом)

Наши ядерные реакторы без всякой жавы, на лампах)))

Ну, у этой библиотеки есть и кроме риал-тайма некоторые вкусности: Си совместимые базовые классы Struct и Union (ага!) и (как заявляют разработчики) очень быстрая сериализация в XML и обратно с любой удобной разработчику структурой. Меня эта штука уже из-за выше перечисленных возможностей заинтересовала. Надо прицениться, что и как.

> Ну ничего себе. Всегда же говорили "технология java не подходит для рилтаймовых и критических систем и т.д.". Даже EULA к NT4 на этом очень интенсивно внимание акцентировали. А теперь - пытаются и туда протолкнуть.

При чём тут NT вообще? :)

> Им лишь бы рынок заховать, а про последствия даже не думают. Боюсь представить, что будет, если будут софт для ядерных реакторов на джаве писать, а он в тот момент, когда нужно на датчик отреагировать, решит garbage collector'ом по структурам пройтись.. Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

Сходи по ссылке, там всё написано. И про gc, и про библиотеку.

> когда нужно на датчик отреагировать, решит garbage collector'ом по структурам пройтись...

1) GC - низкоприоритетный процесс, и его можно отключить и запускать вручную. 2) там по ссылке про аллокацию памяти кое-что написано...

[:|||||||||||||:]

>Боюсь представить, что будет, если будут софт для ядерных реакторов на джаве писать, а он в тот момент, когда нужно на датчик отреагировать, решит garbage collector'ом по структурам пройтись..

А когда ты вызываешь в C++ delete p; ты можешь гарантировать время деструкции неизвестного дерева неизвестных объектов?

Ты не бойся, ты изучай...

> в Javolution память преаллокируется, так что сборщик почти не нужен

вот именно - "почти". это значит, что нужен.

Полез было с замечанием, как они с javolution-классами Java разбираться будут... А оказалось, что это - тот самый Javolution и есть.

Не знаю, что они там на RT мутят, но FastList/FastTable/etc - великолепные классы :)

ну вы даете.. Javolution это же очень, нет очень-очень старая штука...

> некоторые вкусности: Си совместимые базовые классы Struct и Union (ага!) .... Меня эта штука уже из-за выше перечисленных возможностей заинтересовала. Надо прицениться, что и как.

Любитель джавы с нестандартным синтаксисом?

> Любитель джавы с нестандартным синтаксисом?

Нет, просто люблю свободу мысли и действия. Как правило, такие изыски в большинстве случаев не нужны, однако, как в анекдоте про поручика Ржевского, случаи-то разные бывают...

Пишу TCP сервер сейчас на java - уже скачал, сейчас буду пробовать=)

>> в Javolution память преаллокируется, так что сборщик почти не нужен

>вот именно - "почти". это значит, что нужен.

почти - это означает только для не-RT задач (например - старт системы), по потребности. для RT он польностью исключаем

В общем-то они правильно пишут. Те технологии, которые сейчас предлагают Sun и IBM недостаточно хороши - они гарантируют предсказуемость виртуальной машины, но не гарантируют предсказуемость библиотек.

При этом, конечно же, то, что предлагает Javolution само по себе не может называться как hard real-time, так и soft real-time.

Ой, щито вы говорите?

Jewolution?

Кодить теперя будем на кошерной Jewa?

> Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

Видимо, изменилось значение термина realtime. Сейчас, видимо, реалтайм - это нечто жутко тормозящее, глючащее и перезагружающееся по таймеру (спасибо анонимфусу). Но не без ынтырпрайза, ага. Куда ща без него?

http://www.linux.org.ru/view-message.jsp?msgid=726701 http://www.linux.org.ru/jump-message.jsp?msgid=816831 http://www.linux.org.ru/view-message.jsp?msgid=1323868

> В общем-то они правильно пишут. Те технологии, которые сейчас предлагают Sun и IBM недостаточно хороши - они гарантируют предсказуемость виртуальной машины, но не гарантируют предсказуемость библиотек.

Про J9 VM от IBM спорить бессмысленно -- о ней здесь никто (и я в т. ч. ) не знает ничерта толком.

Что касается стандартных HotSpot/Server VM от Sun, то, во-первых, они сами по себе вочень большой степени поддаются настройке (это может не быть даже soft RT, но в 90% случаев вырешите свои проблемы с производительностью, потому как настоящий RT нужен редко и совсем не вам), а во-вторых, Sun сейчас разрабатывает Java Real-Time System, которая отвечает требованиям RT, но, увы, доступна узкому кругу лиц.

Я с год назад щупал эту штуку (под Solaris). GC (и ещё нескольких привычных вещей) там вообще нет. Как они справляются -- неведомо :)

>> Боюсь представить, что будет, если будут софт для ядерных реакторов на джаве писать

>Есть менее ответственные системы, есть soft realtime. Теоретически, с хорошо настроенным сборщиком мусора, Java подходит для soft realtime.

Не знаю о чем новость - у меня вот на столе лежит Concurrent & Realtime Programming in Java by Andy Wellings, 2004 год, там описана RTSJ, которая была написана насколько я понимаю для спарков. Там используется подсчет ссылок и неудаляемая память для того чтобы GC не мешал.

Собственно, я был несколько не в теме и потому нагнал. Завесу уже слегка приоткрыли. Щупайте:

http://java.sun.com/javase/technologies/realtime/rts/

>Кодить теперя будем на кошерной Jewa?

Лучше на Zewa :)

>Не знаю о чем новость - у меня вот на столе лежит Concurrent & Realtime Programming in Java by Andy Wellings, 2004 год, там описана RTSJ, которая была написана насколько я понимаю для спарков. Там используется подсчет ссылок и неудаляемая память для того чтобы GC не мешал.

Так новость не для таких как ты, которых еще мало и страшно далеки они от народа, а для тех "программахеров", которым мама не купила книгу Concurrent & Realtime Programming in Java и которые верят, что жаба тормозное глючное гуано, жрущее многа памяти. Типа их-то программы уж многа памяти не жрут

>Не знаю о чем новость - у меня вот на столе лежит Concurrent & Realtime Programming in Java by Andy Wellings, 2004 год, там описана RTSJ, которая была написана насколько я понимаю для спарков. Там используется подсчет ссылок и неудаляемая память для того чтобы GC не мешал.

RTSJ никак не привязана к архитектуре процессора. Суть RTSJ в том, чтобы добиться более предсказуемого поведения JVM, посредством дополнительного API, а имменно, избежать задержек связанных со сборщиком мусора, сделать более предсказуемый scheduling, решить проблему с priority inversion и многое другое.

По этому поводу есть небольшой русский блог http://blogs.sun.com/vmrobot/category/Real+Time+Java

> По этому поводу есть небольшой русский блог http://blogs.sun.com/vmrobot/category/Real+Time+Java

Да, наши ребята в Ленинграде молодцы. Жаль только, что Иготти из Sun ушёл.

>Они ее на шаттлы ставить будут? :D

шатлакапец ?)))

Всё вышесказанное от ярых поклонников Java напомнило почему-то старые советские времена, когда проблему сначала придумывали а потом с ней боролись. Видимо с настоящими проблемами тяжелее бороться было. А насчёт delete время это извините, на то и realtime чтобы знать сколько и почём каждое твоё действие. И нефиг здесь наворачивать дерево 30 этажей, тем более если не читаешь его код перед внедрением. Вы уж гарантируйте что сегмент кода выполнится в отведённые ему рамки. И при этом желательно таки эффективное использование памяти и процессора. Но видимо всё равно Java рулит, путём введения ещё одного уровня абстракции. Завидую, у нас, у насильников, наоборот если вводишь ещё уровень получаются тормоза.

>Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

Очень просто: 1) Рядом с java никаких процессов нет. Java - процесс единственный в системе. 2)В java-е запускаем программу реального времени. 3)Все объекты создаются на этапе инициализации. После инициализации никакого выделения памяти! 4)Все ходы такой системы просчитаны с точностью до java-ассемблера.

Обычный Round Robit ;-) Это конечно крайний случай. Просто нужно учесть, что "рилтайм" это скорее не скорость, а предсказуемость!

anonymfus>Ну, например, можно отключить сборщик мусора вообще, но поставить гигантский объём памяти.

Тогда, правда, мы ограничим время непрерывной работы, но многие системы и так регулярно перезагружают по аппаратному таймеру.

Небольшой секрет: почти все RT-программы НЕ используют свободную память в "основном такте" дабы не искушать судьбу ;-). Основной такт - это работа после инициализации системы.

> наоборот если вводишь ещё уровень получаются тормоза.

это похоже неразрешимая проблема - вдолбить людям простую мысль что real-time с производительностью никак не связан, более того - все приличные RT среды тормозят со свистом, и абсолютно не комплексуют по этому поводу, потому как RT - это просто напросто предсказуемость (ну, я бы добавил еще "реактивность", но объяснить, что это тоже не связано с "тормозами" от прослоек вообще нереально), а производительность для тех кому позарез нужен RT достигается элементарно за счет смены железа.

3)Все объекты создаются на этапе инициализации. После инициализации никакого выделения памяти!

Можно привести пример такой реальной системы?

>Как вообще можно создать рилтаймовую библиотеку для по своей природе не гарантирующей рилтайма системы?

Такие библиотеки встречаются повсеместно. Например любой подкласс collection, который содержит в своей основе массив, расширяющийся по мере заполнения. В момент расширения происходит непредсказуемая задержка, т.е. метод add/put займет гораздо больше времени, чем обычно.

>это похоже неразрешимая проблема - вдолбить людям простую мысль что real-time с производительностью никак не связан, более того - все приличные RT среды тормозят со свистом, и абсолютно не комплексуют по этому поводу, потому как RT - это просто напросто предсказуемость (ну, я бы добавил еще "реактивность", но объяснить, что это тоже не связано с "тормозами" от прослоек вообще нереально), а производительность для тех кому позарез нужен RT достигается элементарно за счет смены железа.

Все-таки real-time связан с производительностью, ибо если java будучи real-time потеряет в производительности достаточно много и задержки будут в пределах часа, то ей никто не будет пользоваться.

Однако на сегодняшний день Sun Real-Time Java гарантирует задержки десятки микросекунд при использовании памяти, в которой не работает сборщик мусора, и сотни микросекунд для потоков, работающих в хипе + real-time сборщик мусора.

>Можно привести пример такой реальной системы?

Всемирно известных не знаю ;-) Все те, которые мне доводилось видеть и в создании некоторых учавствовал были такого рода: 1)Станции управления асинхронными и вентильными двигателями 2)Комплекс наведения ракеты 3) Система целеуказания самолёта 3)Робототехника (различная ультразвуковая диагностика) 4)Автоматизация.

Все программы были созданы на РАЗНЫХ предприятиях (институтах).

Хочу пояснить высказывание "3)Все объекты создаются на этапе инициализации. После инициализации никакого выделения памяти!" Имелось ввиду, что никакое использование свободной памяти после инициализации НЕДОПУСТИМО. Автоматические объекты конечно же создавать можно ;-). Кстати это тоже головная боль - нужно контролировать размер стека.

>Все-таки real-time связан с производительностью, ибо если java будучи real-time потеряет в производительности достаточно много и задержки будут в пределах часа, то ей никто не будет пользоваться.

Согласен! Это второй пункт после "предсказуемости". Конечно разработчик при выборе смотрит и на времена реакции системы на внешние события (прерывания).

Думаю что часть рынка, где java может потеснить C/C++ это safety critical embedded. Эта область задач очень близка к realtime embedded. Выскажу предположение, что Javolution нацелен именно на safety critical embedded. Приложения такого класса должны быть прежде всего надёжны и отказоустойчивы.

>Хочу пояснить высказывание "3)Все объекты создаются на этапе инициализации. После инициализации никакого выделения памяти!" Имелось ввиду, что никакое использование свободной памяти после инициализации НЕДОПУСТИМО. Автоматические объекты конечно же создавать можно ;-). Кстати это тоже головная боль - нужно контролировать размер стека.

Ну это уже совсем другое дело. Ни одна система не может обойтись только статическими данными, хотя в любой системе они обязательно есть. А то что ты называешь автоматическими объектами, в real-time java называются объекты, аллоцированные в scoped memory. Там тоже много чего надо контролировать, но при этом тебе не мешает сборщик мусора.

>Всемирно известных не знаю ;-) Все те, которые мне доводилось видеть и в создании некоторых учавствовал были такого рода: 1)Станции управления асинхронными и вентильными двигателями 2)Комплекс наведения ракеты 3) Система целеуказания самолёта 3)Робототехника (различная ультразвуковая диагностика) 4)Автоматизация.

Да ты крут! :)

>Думаю что часть рынка, где java может потеснить C/C++ это safety critical embedded. Эта область задач очень близка к realtime embedded.

"Ты знаааал, ты знаааааал!"© http://www.embeddedtechmag.com/index2.php?option=com_content&task=view&am... http://www.sdtimes.com/article/latestnews-20070815-04.html

http://www.google.ru/search?q=JSR+302++java+safety+critical

> то похоже неразрешимая проблема - вдолбить людям простую мысль что real-time с производительностью никак не связан

Дык ёлы-палы, любая программная система - это система РВ, если время реакции задать пару лет :)

С детства помнится фраза из описаня к Java, как то: не используйте сие детище на критических объектах и системах с высоким уровнем опасностей

Детство затянулось ппц не по детски

Одно только непонятно, под какой операционной системой должна запускаться эта самая real-time Java? ОС насколько я понимаю тоже дплна быть real-time...

Более того, давно известно, что производительность "нериал-тайм" систем может значительно превосходить по производительности "риал-тайм" системы. Учите матчасть!