[дикость] delete в Java

А что мешает просто удалять ссылки на объекты? Нет ссылки - нет объекта и gc все уберет.

> А что мешает просто удалять ссылки на объекты? Нет ссылки - нет объекта и gc все уберет.

Во-первых: иногда это нужно сделать во время исполнения функции. Во-вторых: на исполнение GC нужно время, это не самая быстрая задача. Поэтому её прогон тоже происходит не очень часто, так что приложения, которые активно используют память, могут разрастаться в промежутках между срабатываниями GC.

тонко

Потому что:
* тормоза бы возросли (частые вызовы GC)
* NPE бы сыпались ведрами

> тормоза бы возросли (частые вызовы GC)

А вот не факт. Да и кто сказал, что для очистки памяти обязательно вызывать GC?

> NPE бы сыпались ведрами

Как напишешь, так и будет. Не надо перекладывать с больной головы на здоровую.

> А что мешает просто удалять ссылки на объекты? Нет ссылки - нет объекта и gc все уберет.

Во-первых: иногда это нужно сделать во время исполнения функции. Во-вторых: на исполнение GC нужно время, это не самая быстрая задача. Поэтому её прогон тоже происходит не очень часто, так что приложения, которые активно используют память, могут разрастаться в промежутках между срабатываниями GC.

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

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

Пример. Я обрабатываю поток высококачественных изображений, несколько изображений в секунду. Очевидное решение - подгружать их с HDD в объект, из которого извлекать и парсить матрицу пикселей. Но при этом программа начинает жрать пару ГБ оперативы, ибо GC не справляется.

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

А так нобади керес.

Как напишешь, так и будет.

Ага, с чего начали, к тому и вернулись. Прекрасно я считаю.

myClass=null; System.gc();

не то разве??? практически тоже самое что и delete

Очевидное решение

Загружать данные поверх существующих объектов.

> не то разве??? практически тоже самое что и delete

Во-первых VM не обязана исполнять System.gc() сразу, и вообще не обязана его исполнять. На усмотрение. Во-вторых, как говорилось выше, gc() - весьма медленный процесс, а значит, лишние тормоза обеспечены.

> Загружать данные поверх существующих объектов.

Ну да, давай городить парсер PNG ещё, чтобы подгружать всё в массив. Не проще ли иметь такую удобную и простую штуку, как delete?

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

> Ага, с чего начали, к тому и вернулись. Прекрасно я считаю.

Как я уже говорил выше: а) NPE легко устранимы, т.к. имеем managed-код б) не хочешь нарваться на NPE - не юзай delete, GC сам справится.

> ну так убивай принудительно GC только те классы/данные которые заведомо могут захватить огромные массивы памяти, в противном случае разговор ни о чем.

А ну-ка, как уничтожить конкретные данные, не сделав полный прогон GC?

обрабатывай через jni, раз уж изображения такие большие

> Пример. Я обрабатываю поток высококачественных изображений, несколько изображений в секунду. Очевидное решение - подгружать их с HDD в объект, из которого извлекать и парсить матрицу пикселей. Но при этом программа начинает жрать пару ГБ оперативы, ибо GC не справляется.

При таком примере GC у вас никогда не справится потому как вызывается очень редко. Мастырить сотни таких объектов и ждать кода их грохнет GC не самый удачный алгоритм. Я не очень пока ещё силён в java, но полюбому изначально такой алгоритм не стал бы использовать. delete бы вам не сильно помогло потому что сильно бы снизило скорость работы программы высвобождая память за каждым объектом.

Это просто умозрительный эксперимент, показывающий, что delete вполне можно юзать.

> Это просто умозрительный эксперимент, показывающий, что delete вполне можно юзать.

У нас разные подходы. Вам лучше удалять лишнее, мне лучше лишнего не делать.

ну батенька, концепция подхода разная, полный прогон GC не так сильно нагружает систему как почему то Вы показываете, т.к. это происходит периодически, то почти не заметно даже на слабых машинах. Если бы все было так ужасно, то java не была бы встроена ни в java-карты, ни в мобильники(имею ввиду старые еще черно-белые). Как показала жизнь, GC справляется прекрасно со своими задачами и городить еще костыли ввиде delete не уместно, хотя и есть кажущаяся на первый взгляд выгода, но это не более чем параноя, особенно на мощных машинах. Сам первое время ею страдал)))) Принудительный вызов System.gc() как показывает практика, обычно вызывается сразу и в большинстве случаев отрабатывается с освобождением памяти, конечно на каждый чих он не должен вызываться...

Хотелось бы услышать, посредством какого либастрала, будет NPE ^_^

Давай вместе последим за твоими рассуждениями, революционер ты наш.

годный вброс.

> Хотелось бы услышать, посредством какого либастрала, будет NPE ^_^

По всем вопросам к urxvt

Но ведь удалять только конкретный объект в любом случае будет быстрее, чем делать полный прогон, не так ли? Может, стоит проверить, есть ли выгода на практике? (например, скомпилить в таком режиме какой-нибудь большой проект).

>При таком примере GC у вас никогда не справится потому как вызывается очень редко. Мастырить сотни таких объектов и ждать кода их грохнет GC не самый удачный алгоритм. Я не очень пока ещё силён в java, но полюбому изначально такой алгоритм не стал бы использовать. delete бы вам не сильно помогло потому что сильно бы снизило скорость работы программы высвобождая память за каждым объектом.

Поддержу, накладные расходы на постоянный delete ~ к накладным расходам периодического gc.

>Пример. Я обрабатываю поток высококачественных изображений, несколько изображений в секунду. Очевидное решение - подгружать их с HDD в объект, из которого извлекать и парсить матрицу пикселей. Но при этом программа начинает жрать пару ГБ оперативы, ибо GC не справляется.

Объекты не нужно мастырить, а нужно перезаписывать их, выделив максимально возможный/нужный для самого большого объекта массив памяти...

По всем вопросам к urxvt

То есть ты с ним не согласен. И при удалении объекта все будет чики-поки?

А у меня третье мнение. delete вырождается или в неуправляемый рантайм или в system.gc. То есть, не нужен в любом случае.

> Поддержу, накладные расходы на постоянный delete ~ к накладным расходам периодического gc.

Расходы CPU. А расходы RAM меньше.

> То есть ты с ним не согласен. И при удалении объекта все будет чики-поки?

Я ещё не смотрел реализацию удаления объектов внутри GC. Поэтому судить о реализации не могу.

>особенно на мощных машинах.

ненавижу такой оборот. что, если машина мощная - так экономия ресурсов ненужна?

И останутся после этого висячие ссылки.

Поэтому судить о реализации не могу.

То что ты жирная троллина было понятно с самого начала.

> И останутся после этого висячие ссылки.

А щас, типа, нельзя variable=null сказать? Ничего не изменится.

> То что ты жирная троллина было понятно с самого начала.

С какого перепугу? Просто у меня возник вопрос, я задал его на ЛОРе. Предварительно скачал сырцы JVM, но пока не смотрел.

> А щас, типа, нельзя variable=null сказать? Ничего не изменится.

тогда останутся висячие объекты, как их искать собираетесь чтобы удалять?

Современные коллекторы ОЧЕНЬ эффективны. А вот давая такие прямые указания на удаление Вы мешаете коллектору работать эффективно. Просто укажите ему, что данный объект больше не нужен, с остальным он как-нибудь сам.

> тогда останутся висячие объекты, как их искать собираетесь чтобы удалять?

Я не говорил «отказаться от GC вообще». Я сказал лишь «ввести способ принудительного освобождения памяти». Все висячие объекты, как и прежде, будет убивать GC.

ввести способ принудительного освобождения памяти

Он уже есть. Убираешь все ссылки на объект. Вызываешь gc.

нужна, но не настолько сильно, как учили в свое время... т.к. экономия порождает параною, которая заставляет программиста не писать решение задачи, а сидеть и оптимизировать до опупения свой код и это сказывается в итоге на качестве продукта и скорости программирования в целом))) Есть задачи где нужно биться за каждый бит, но сейчас концепция наращивания мощности машин сводится к упрощению жизни программиста, чтобы программа писалась быстро, с меньшими ошибками и издержками и чтобы программист сосредоточился на функционале, а не на системных проблемах.

> Он уже есть. Убираешь все ссылки на объект. Вызываешь gc.

Как уже много раз говорилось выше, это неоптимальный путь, даже исходя из здравого смысла.

> Я не говорил «отказаться от GC вообще». Я сказал лишь «ввести способ принудительного освобождения памяти». Все висячие объекты, как и прежде, будет убивать GC.

Я считаю так - если GC не справляется надо пересматривать алгоритм или подход.

даже исходя из здравого смысла.

Второй раз прошу. Приведи цепочку рассуждений. Здравую, хе-хе.

> Второй раз прошу. Приведи цепочку рассуждений.

Рассуждения сводятся к тому, что GC вынужден выполнять сложный алгоритм полной проверки участков памяти, тогда как delete просто удалит вполне конкретный участок.

тогда как delete просто удалит вполне конкретный участок.

И получим неуправляемый рантайм? Выдыхай, товарищ!

А щас, типа, нельзя variable=null сказать? Ничего не изменится.

Ну занулил ты одну ссылку и что дальше?

> И получим неуправляемый рантайм?

Да с чего вы вообще взяли, что получим неуправляемый рантайм? Где аргументация?

> Ну занулил ты одну ссылку и что дальше?

Если ссылка была единственной, GC подчистит.

Сборка мусора с поддержкой ручного удаления скорее всего будет работать хуже, чем без поддержки. Я плохо представляю себе, по какому принципу должен работать такой сборщик мусора, чтобы быть эффективным, и ещё хуже представляю себе, как определять разыменование удалённого объекта.