Pull to refresh

Comments 17

Интересно под конец написали :)
А как вы сделали вывод про java/c#? У вас же плюсовый демон. В managed environment той ошибки, что вы написали, просто бы не было
ну в языках с настоящим gc конечно немного по другому, но как ни странно в них тоже есть утечки (я сам удивился, когда гуглил аллокаторы памяти и тулзы для анализа утечек).
ни и ещё друзья, которые професионально пишут на java, тоже пугали всякими страшилками;)
но сама идея в том, что минимизируя риск утечек, к примеру используя только контейнеры и умные указатели, все равно можно выстрелисть себе в ногу, но разобраться в причине будет намного сложнее.
Не, это я знаю :) Просто интересно, что именно заставило вас обобщить опыт на управляемые языки. По опыту могу сказать, что разный long-running софт, в котором выделяется и освобождается память всяко лучше писать на чем-нибудь с gc; ну и там другого рода утечки, чаще всего те, что называются «висячие указатели», а так же различного рода костыли и костылики. К счастью, детектить там это не в пример проще.
Но вот грамотный плюсовый демон будет работать куда быстрее и с меньшим потреблением памяти. Ну и разумеется managed код совершенно не годится для всякого рода систем реального времени. Там даже динамическая память то может быть опасна!
Тут какбе в другом заминка — вопрос создания «грамотного» плюсового демона (да и не демона) надо рассматривать в разрезе (как я себе вижу) затрат на него. Создание «грамотного» демона на плюсах у вас потребует много больше усилий, чем gc; т.е. отдача меньше.
А так — да, для марсоходов, например, пишут на Сях :) Получается крайне шустро и компактно, ни одна Java не угонится. Тока пишут медленно. Очень.

Второе вот что: честно говоря, я не знаю, что вы понимаете под системами реального времени. Но если что, то для той же java есть realtime gc. Поищите, если вправду тема интересна.
Не обязательно весь демон писать на плюсах, мы к примеру часть логики выносим в скриптовый язык (lua, но можно к примеру использовать mono) и получается замечательная комбинация требовательного по производительности кода на C++ и не требовательной бизнес логики на lua. Это даёт возможность для маневров (оптимизация узких мест), но не слишком замедляет разработку (код на lua пишется на порядок быстрее).
По поводу марсоходов, я слышал что они пишутся на Ada, языке в котором можно доказать, что в нем нету ошибок (утверждать не бурусть, но это запало в память;)
Real-time java — да, слышал. Но думаю, что не все продвинутые джавистя сходу справятся с этой задачей.
Не, я же не против вашего подхода. Мне вот нравится. Даже больше, считаю (как и вы, как оказалось), что совать брутальный low-level не во все задачи имеет смысл. Мир :)
>Второе вот что: честно говоря, я не знаю, что вы понимаете под системами реального времени. Но если что, то для той же java есть realtime gc. Поищите, если вправду тема интересна.

Это система, где задержка больше определённого порога ведёт к отказу системы. Тут ни один GC не подойдет
Почему не подойдет? Давайте пойдем от вашего определения. Я пока игнорирую «отказ системы», потому что это сложное понятие, определение которому вы не даете =)

Однако, к тому, что есть: у вас упомянута такая величина — «определенный порог времени». Пусть определенный порог = 1час. В таком случае даже десктопная джава удовлетворяет этому критерию. Противоречит ли мое предположение вашему определению? Нет, соответствует полностью. Значит, десктопная java — система реального времени =) А что, математически я все верно сказал, прикопаться не к чему.
Теорию бы почитали внимательнее. Опять вы все говорите про длительность отклика, а он должен быть ГАРАНТИРОВАННЫМ. GC в java не может обеспечить гарантированное время отклика by design. Он просто может взять и заморозить приложение в самый неподходящий момент.
>В managed environment той ошибки, что вы написали, просто бы не было

Утечку памяти, тем не менее, организовать весьма легко
Изобразите? :)
Ну создай массив на over 9000 нулей, запихни его в какой-нибудь синглтон, чтобы сборщик мусора был уверен, что он нужен, и забудь о существовании этого массива.
????
PROFIT
Так он же не утечет — ну выделится память под него и все, расти не будет. Имхо это не утечка; да и потом, он как рут будет доступен, и его всегда будет видно (тем же sos, если это .net). Так неинтересно :)

P.S. Вы реально такой код на продакшене пишете, с синглтонами и забытыми нулями?
Вы же отмечались в статье про LOH и Chunked List, т.ч. о существовании инструментов для создания кривого приложения знаете. другое дело что придуется серьезно «покривляться» чтобы память всю отъесть, но ведь можно если постараться :D
Да, но там в статье не память течет, а адресное пространство — несколько разные вещи, к тому же зависящие от отдельно взятой реализации GC. В 4ом .net — возможно — обещают compacting loh, так что эта проблема снимается.
недавно поставил сервер для хостинга. С ним что-то не то. При активном использовании зависает. Пять минут кликая по какой-то ссылке, у меня получилось заДДоСить его =) На выходных буду ковырять
Sign up to leave a comment.

Articles