> try-catch в современных языках программирования никто не отменял.

И что? В обработчике исключения далеко не все удосуживаются написать что-то осмысленное. А если уж хочется пообрабатывать ошибки осмысленно - даже на гольных сях это можно. Приколитесь? :)

> В блоке catch программа может определить неполадки

Даже на самых простых сях тоже можно заменить дефолтный обработчик на что-то свое, и когда случится жопа, управление получит не дефолтный обработчик а ваш код. А 10 отличий - они в чем состоят?  

>  и попытаться восстановить своё состояние до входа в блок try.

Попытаться... да... удачи в этом начинании. На сях ксати тоже можно попытаться. А почему нет? Напримре в *никсах программа может навесить свои кастомные обработчики сигналов. На SIGSEGV в частности. Чем это будет так уж сильно отличаться от того же try-catch на большой блок кода? Если вы этого вдруг не знали - наверное в этом не си все-таки виноват, а вы? :)

> В большинстве случаев такое поведение несмертельно для программы

Ну так я уже сказал что если на ошибку положили болт - есть ровно 2 варианта что будет дальше: можно глюк обнаружить и убить программу. А можно не убивать и предоставить ей работать дальше. Только дальнейшее ее поведение будет неопределено. При том мне подход с пристреливанием при обнаружении потенциально фатального глюка как-то более симпатичен: способствует фиксингу этих самых глюков, а не предоставляет глюкастику глюкавить себе дальше в надежде что авось пронесет.

>> как билетная касса: у вас могут все разобрать перед самым носом.
> Это — задача операционной системы и/или JVM.

Спасибо, Кэп. А я то и не подозревал что в роли кассы именно они.

> Пока что JVM показывает наилучшее управление ресурсами,

А JVM вааще является в этой нашей схеме с билетами всего лишь спекулянтом-перепродавцом билетиков, который получает билеты в той же кассе (у OS) и потом их вам перепродает. И, кстати, если вдруг спекулянта обломают в кассе с билетами - он и вас обломает при попытке купить у него билет, т.к. если у него нет билетов, взять ему их будет неоткуда. Плюс он может вас обломать если его лучший друг попросил придержать для него билетиков. Или если ему не нравится ваша морда лица. Или ... ну в общем ява может иметь свое мнение о том сколько вам память можно. Вторым уровнем, опосля мнения ОС на этот счет. Странно, правда? Утверждается что сие надежнее чем напрямую забронировать билет? Ну да, помечтайте :) В одном случае 1 точка отказа, в другом - 2, при том первая - такая же как в первом случае. С фига ли цепь из 2 звеньев лучше чем из одного по надежности? Вы жестоко прогуливали теорвер в инсте, или WTF? :)))

> чем, собственно, ядро ОС,

А ява, кончно же, совсем не через обосранное вами ядро этой самой ОС память выделяет, правда? Скажите, ну как можно настолько ламернуться то? В общем FAIL :)

> глядя на то, как "текут картинки" и обваливается Xorg. :))

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

> В JVM есть разные стратегии распределения памяти и уборки мусора.

А *свою* стратегию - возможно подсунуть? Или как обычно - 640 Кб хватит всем, потому что умные дяди из сан/оракл так за вас решили?

> Под разные задачи можно выбрать оптимальные.

А парни из сана и оракла обладают телепатией чтобы предвидеть ВСЕ возможные типы задач?

> Краткая история развития технологии утилизации памяти:

Да, термин "утилизация" применительно к яве неплохо описывает то что оно делает с памятью :D.

> Сборка мусора и производительность:

Мануал о том как сперва создать себе 100500 проблем а потом мужественно с ними бороться. По-моему, если уж волнует производительность, особенно гарантированная - нехрен связываться ни с явой, ни с гарбаж коллекторами.

> А зачем в программе на Java выделять себе память?

Да хоть горшком назовите. Созданием объекта, или как вам там угодно. В конечном итоге - это будет с точки зрения ОС трансформировано в выделение памяти, один хрен. Потоу что ядро не оперирует такими терминами. А как вы это там назовете - не так уж и интересно. Ну не malloc у вас сможет обломится, так new. И если скажем объект не создался и он был не для красоты - врядли получится корректно поработать дальше, правда? :) А 10 отличий - они в чем будут? Так, глобально? :)

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

Ну да, конечно. Ведь с new но без delete при активном создании объектов поиметь неочевидные утечки памяти - ни разу не проблема, правда? :))) Ведь достаточно оставить по недосмотру ссылку на какой-то временный объект, и GC его уже никогда не убьет. И будет .... утечка памяти! Та самая, которая якобы "невозможна" на яве, хи-хи ;).