vitaly_spb,

> ПК>Что характерно, зачастую -- задолго до.
>
> ну да, я к тому что это не из-за кривых программистских рук просто есть обстоятельства, которые программисту не обойти

А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?

ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?

В задаче своевременного никак не помогают, они помогают в задаче гарантированного освобождения ресурсов. Но вопрос собственно ставился по-другому, а именно: "в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?".

Здравствуйте, vitaly_spb, Вы писали:

IT>>Я вот другого не пойму. Что же вы все так за бедолагу GC переживаете?

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

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, c-smile, Вы писали:

CS>>Т.е. она идеологически правильная но практически не работает — тормозит.

IT>Графика в .NET тормозит не по причине GC, а по пречине того, что она базируется на GDI+.

Наверное.
Такое впечатление что GDI+ была сделана врагами специально чтобы .NET не разгонялась...

Почему не сделать так?

-Drawing
+--DrawingPlus

?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, n0name2, Вы писали:

N>>>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.

IT>>>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.

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

IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.

В окамле это давно работает
Посколько внутри камл-программы мы вообще не видим никакого стека, ни регистров ничего такого, то компилятор этим нагло пользуется и раскидывает данные так, как ему удобно
за 15 лет ничего не сломалось :)
да не только окамл, большинство ML-компиляторов, Clean и Haskell так делают
теперь вот до Жабы на третьи сутки дошло :)

Здравствуйте, n0name2, Вы писали:

N>да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ.

В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.

N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?

Не знаю. Смахивает на неудачную попытку изобразить дестркуторы.

Здравствуйте, reductor, Вы писали:

R>В окамле это давно работает

Работает или есть и иногда при очень удачном стечении обстоятельств используется? Сдаётся мне, что там столько НО!, что в реальном коде это почти не может быть использовано.

R>теперь вот до Жабы на третьи сутки дошло

Ну дай то бог

Здравствуйте, c-smile, Вы писали:

IT>>Графика в .NET тормозит не по причине GC, а по пречине того, что она базируется на GDI+.

CS>Наверное.
CS>Такое впечатление что GDI+ была сделана врагами специально чтобы .NET не разгонялась...

Очень похоже. Одно только то, что в GDI+ невозможно установить отдельно стоящий пиксель уже наводит на некоторые размышления

IT,

> N>да ну? это парадигма в дотнете чтоли такая — заставим ЖЦ подольше работать (даже concurrent коллектору иногда надо останавливать всю систему) выполняя финалайзеры? тогда понятно почему тут народ так заботится о ЖЦ.
>
> В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.

Но на время отдельных фаз (в зависимости от режима) GC все потоки приостанавливаются, и Finalize определенно замедляет GC.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, reductor, Вы писали:

R>>В окамле это давно работает

IT>Работает или есть и иногда при очень удачном стечении обстоятельств используется? Сдаётся мне, что там столько НО!, что в реальном коде это почти не может быть использовано.

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

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

Я, кстати, кажется, даже видел какие-то работы автора окамла (Ксавье Лерой) по верификации java-байткода.
Лень сейчас смотреть, но может статься, это даже связано с.

Здравствуйте, Pzz, Вы писали:
Pzz>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем
Pzz>более, что в форточках 1) процесс обычно имеет 2 GB адресного
Pzz>пространства, а не 3, как в линухе 2) в форточках потоками принято
Pzz>пользоваться активно.
В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем? А в обычных случаях рекурсии (типа обхода дерева) такие глубины на практике недостижимы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не совсем так. Объект никуда не исчезнет, он просто переинициализируется. В конце концов мог бы он себя переинициализировать так

PD>C c = new C(...);
PD>// use
PD>c.prop1 = ...;
PD>c.prop2 = ...;
PD>// etc.

PD>а это ничем не отличается от повторного вызова ctor в конечном счете. Я ведь не имею в виду, что объект заново размещается, а только изменяет свое состояние так, как если бы все его поля "исчезли" и были установлены заново.
Ну, для immutable объектов такое непозволительно. Вот, скажем, если у нас есть строка, то ее нельзя "переинициализировать", т.к. ссылающийся на нее код полагается на ее принципиальную неизменность. Таких объектов довольно много — например, System.Drawing.Font.

S>>Выделение памяти в управляемой среде — сверхестественно дешевая операция, сравнимая со стоимостью выделения памяти на стеке в C++. Не там воду ищешь.

PD>Выделение — да. Но не сжатие кучи. А вот там сжимать пришлось бы меньше. Представь себе. что тебе нужно по ходу действия создать десяток кистей. Сейчас для каждой new, потом их всех уберет GC. В моем варианте new будет один, так что и ему придется лишь один объект убрать.
Гм. Павел, быстродействие GC в первом приближении зависит не от количества умерших объектов, а от количества живых. Если об этом помнить, то все встанет на свои места.

Здравствуйте, IT, Вы писали:

IT>В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.

даже если бы это было полностью верно, никто не гарантирует что, скажем, незакрытый File подберется в течении ближайших суток (если он вдруг успел запромоутится в permanent generation). ЖЦ это только средство управления памятью а не системными ресурсами. не надо его юзать для того, для чего он не предназначен изначально.

Здравствуйте, vitaly_spb, Вы писали:

>в задаче гарантированного освобождения ресурсов

?????....

а разве в java finalize() что нибудь гарантирует? они не гарантируют

вот поэтому и ...

>"в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются."

>> Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?

ПК>Что характерно, зачастую -- задолго до.

если это сервер, то поняимя "закрыть приложение" не существует — он практически всегда расчитан на то что он работает месяцами без остановки (хотя, конечно, под виндой если недельку продержится и то хорошо

при закрытии программы OS сама закроет все сокеты, файлы и т.д. и т.п., освободит всю память даже если ее не подобрал ЖЦ и т.д. без всяких финалайзеров.

try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов. MS фактически поощряет очень опасный стиль программирования. лучше 100 goto чем 1 финалайзер. и всякие хинты для ЖЦ это тоже самое что проверка в компиляторе — если ли коментарий перед goto объясняющий зачем он тут стоит и почему нельзя сделать цикл.

Sinclair wrote:

> В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой
> фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я
> конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять,
> но черт возьми — /зачем/? А в обычных случаях рекурсии (типа обхода
> дерева) такие глубины на практике недостижимы.

Кстати, стек еще и расти сам умеет.

--
С уважением,
Alex Besogonov (alexy@izh.com)

CS>

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

Вот-вот, великая тройка: MS, GC и .NET

Здравствуйте, Sinclair, Вы писали:

S>В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем?

А пофик.
Ты прикинь, сколько это будет — 1024-е число Фибоначчи. И зачем их вообще вычислять? Реально этих чисел используется — всего-навсего сотня, ну две.
Я, конечно, понимаю, что пример абстрактный, просто так, к слову.

n0name2,

>>> Ссылка на файл, ссылка на соединение и т.п. вещи. Их нужно закрывать после закрытия работы приложения (к примеру), правильно ведь?
>
> ПК>Что характерно, зачастую -- задолго до.
>
> если это сервер, то поняимя "закрыть приложение" не существует

+1.

> try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов.

-1. using in C#, RAII in C++.

Sinclair wrote:
>
> Pzz>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем
> Pzz>более, что в форточках 1) процесс обычно имеет 2 GB адресного
> Pzz>пространства, а не 3, как в линухе 2) в форточках потоками принято
> Pzz>пользоваться активно.
> В винде вроде бы мегабайт. Ну пусть у нас толстая процедура, у которой
> фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я
> конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но
> черт возьми — /зачем/? А в обычных случаях рекурсии (типа обхода дерева)
> такие глубины на практике недостижимы.

Это если считать, что программисты — люди разумные. Однако бывают и
такие, которые на стеке большие буфера заводят...