Началось все с того, что Алёна Сагалаева (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 комментария:
Я тоже послушал (еле выдержал) :) Ни одного радио-т более не осилю, поскольку радио слушаю из-за музыки а не за болтовню диджеев.
Не могу назвать это наездом, основная претензия - слишком сложный язык. Давно на арене, а инструментов аналогичных 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
Отправить комментарий