воскресенье, 23 января 2011 г.

[prog] Несколько ссылок на тему Real-Time Java

Началось все с того, что Алёна Сагалаева (aka Alena C++) сообщила в своем блоге об участи в подкасте некоего Радио Т. Прослушал я этот подкаст. Подивился ущербности наездов на C++ со стороны ведущих – обсуждение C++ там велось в стиле “Алёна, всем давно известно, что C++ унылое говно. Что вы можете сказать по этому поводу?” Отдаю должное Алёне, она держала себя в руках. Я бы на ее месте быстро бы перешел к ответам вроде “Уже давно очевидно, что вы дятел. Что вы можете сказать по этому поводу?”

Среди потоков феерического бреда в подкасте так же прозвучала фраза о том, что в Java есть ручное управление памятью. Из того, что я знаю про Java, ручное управление памятью там было только в Java-расширении под названием Real-Time Specification for Java (RTSJ). Помню, что на глаза попадались какие-то статьи с рассказом о том, что же RTSJ добавляет в Java в плане управления памятью. Но, как назло, ничего конкретного не вспомнил. Поэтому немного погуглил и нашел несколько ссылок. В общем, ничего серьезного, но в качестве отправной точки для заинтересовавшихся данной темой подойдет.

Во-первых, это краткий обзор RTSJ на сайте Sun Oracle: An Introduction to Real-Time Java Technology: Part 1, The Real-Time Specification for Java (JSR 1). Это очень краткий ввод читателя в тему. Вторая часть статьи лежит здесь.

Во-вторых, это интересная статья “Real-Time Java Scoped Memory: Design Patterns and Semantics” от 2004 года, в которой вопросы управления памятью в RTSJ рассмотрены более подробно, с небольшими схематическими примерами. Чем эта статья еще подкупает, так это тем, что ее писали не саночники-маркетологи, а люди, которые разрабатывали собственную real-time виртуальную машину для Java под названием Ovm. Кстати говоря, на сайте проекта Ovm достаточно много публикаций, касающихся Real-Time Java и попыток ее применения в авиации.

Так вот, саму статью я просмотрел бегло. Не могу сказать, что все в ней понял досконально. В конце-концов, я не Java-программист, и RTSJ никогда раньше не изучал. Просто лет двенадцать назад я был каким-то боком причастен к разработке систем реального времени. Но после прочтения статьи у меня сложилось такое мнение: чего только тупые американцы не придумают, чтобы на C и C++ не программировать :)

Поэтому, программировать на RTSJ, наверное, можно. Но просить за это нужно совсем другие деньги ;) На C++ может выйти дешевле :)))

Ну а в завершение ссылки на небольшие презентации на тему Real-Time Garbage Collector-ов:

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

4 комментария:

Sergey Nikulov комментирует...

Я тоже послушал (еле выдержал) :) Ни одного радио-т более не осилю, поскольку радио слушаю из-за музыки а не за болтовню диджеев.

Не могу назвать это наездом, основная претензия - слишком сложный язык. Давно на арене, а инструментов аналогичных JetBrains Idea или ReSharper (которые тебе все раскрасят и подскажут) нет. Так это всем давно известно.

Просто пацаны собрались постебаться от скуки. Разговор ни о чем... :)

Евгений Охотников комментирует...

@Sergey Nikulov:

>Просто пацаны собрались постебаться от скуки. Разговор ни о чем... :)

Ну да. Таких флеймов на всех проффесиональных ресурсах вроде RSDN, LOR, vingrad и пр. уже не по одному десятку было. Только на форумах, зачастую, в таких срачах очень много интересных ссылок проскакивает. А вот устный стеб на радио в этом смысле оказался ну совсем пустым.

имя комментирует...

недавно читал Uniprocessor Garbage Collection Techniques и отдельно про метроном

мое личное впечатление -- риалтайм в сборке мусора это жуткие тормоза -- т.к. прерванный мусорщик требует или барьер на чтение, или барьер на запись (или forward pointer... торможу щас)

проще, это означает, что *каждая* запись или чтение из кучи требует записи в определенные структуры мусорщика

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

кроме того, есть интересные предложения по типам данных, не допускающим циклические ссылки -- что позволяет использовать счетчики ссылок; есть оптимизации производительности этих счетчиков

З.Ы. твои пдф-ки интересны, почитаю

Евгений Охотников комментирует...

@имя

Еще из недавнего про GC было интересно прочитать про Azul: http://www.artima.com/lejava/articles/azul_pauseless_gc.html