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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>Не знаю о чем новость - у меня вот на столе лежит 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 ушёл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да ты крут! :)

+5