Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, WolfHound, Вы писали:
WH>> public static void AddMemoryPressure(long bytesAllocated);
MS>Спасибо, но это не совсем то. Оно глобальное и работает только с памятью. А прочие ресурсы?
А у тебя память локальная что ли? Ты этим методом информирушь GC о том, что с неким управляемым объектом ассоциировано море неуправляемой памяти. Тот учитывает эту информацию в своих табличках, и далее вызовет GC по раньше, а то и попросту попытается проследить за твоим объектом в первую очередь (не дожидаясь сборки мусора).
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Как можно говорить об эффективности если все вспомогательные объекты удаляются сместе с Graphics?
Да, вот так и можно. Понимаешь, ли отрисовка — это почти вечность по сравнению с временим их создания и уничтожения. Компьютеры то стали отнюдь не детскими игрушками. Вот если пересоздавать те же шрифты при отрисовке каждой ячейке в гриде, то без проблем можно нарваться на тормоза и на современных компьютерах. Но это как правило в сотни, а то и тысячи раз большие потери нежели уничтожение кэша после отрисовки.
Зато экономятся память и ресурсы.
Я вот провел несколько тестов и сделал выводы. А ты на основании чего возмущаешся?
ЗЫ
Ром, ты вот мне объясни. Ты поставил аж три бала тематическому сообщению. Ты вчитывался в код который привел c-smile? Погляди внимательно на фрагменты вроде:
Заметь. Ни о каком кэшировании c-smile не заикался. Сталобыть скорее всего каждый вызов setBrush() приводит к созданию новых объектов ядра и уничтожению стрых. Так что совсем не ясно, что ты так взъелся на мою идею и при этом не предъявляшь тех же претензий к идее c-smile-а? Не уж то предвзятое отношение?
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Ну... если речь о slid-brush, то да. А если о PathGradientBrush, да еще и с Blend/ColorBlend + TransformationMatrix, то аттрибутов много. Учитывая, что Brush — это все-таки абстракция GDI (св-ва заливки), то все простые и сложные случаи выделили в один класс. Pen — тоже самое. И его можно создавать на основе Brush в т.ч..
+1
V>В Java есть своя изюминка. "Маленькие" объекты, область видимости которых не выходит за локальный контекст, JavaVM частенько располагает прямо на стеке. Жаль, что .Net VM пока не умеет аналогичное.
Это называется escape-аанализом. Обещено только в ява 1.6. Так что пока-что этого нет. Но когда появится... боюсь у многих С++-ников будет сильный шок.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
MS>Еще раз. Я хочу завернуть unmanaged ресурс (память, HANDLE, File, etc) в managed wrapper (очень простой, на MC++) и таким образом встроить его в общую схему GC. Точно так же, как это сделано для Brush и прочего. Но поскольку GC не знает, сколько этот объект реально стоит, он считает его дешевым (поскольу в чисто managed он не требует никаких ресурсов). В результате этот объект может жить очень долго. Я хочу всего-навсего иметь механизм ручного "cost estimation", иными словами, чтобы GC мог спросить у объкта, насколько критично его наискорейшее удаление.
Тут дело в том, что ты ячно плохо понимашь как работает ЖЦ. ЖЦ не следит за одним объектом. Он следить на всем хипом. И если ЖЦ посчитает, что нужно очистить нулевое поколение (что обычно происходит и так очень часто), то никто не помещает ему это сделать.
Ты же можешь помочь ЖЦ ускорить сборку мусора указав, что твоей объект удерживает кучу анменеджед-памяти (функцией GC.AddMemoryPressure() от которой ты так пытаешся отпахаться).
К тому же ЖЦ включается если системе начинает нехватать памяти.
Так что единственное что тебе нужно сделать — это не держать жестких ссылок на объекты удерживающие неуправляемую память.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Шахтер, Вы писали:
Ш>Заведи глобальный счетчик дорогих объектов. Как только этот счетчик превысит некоторое пороговое значения -- вызывай GC (в конструкторе класса).
Лучше этого не делать. В МС и так занимаются магией для хэндлов. Погляди под Рефлектором класс System.Runtime.InteropServices.HandleCollector. А воспользоваться им можно через System.Runtime.InteropServices.HandleCollector.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
N>>в Жабе 1.6 будет стековая аллокация — компилятор после того как выполнит все inline посмотрит можно ли все сделать на стеке или нет. т.е.
IT>Боюсь что подобная фича будет представлять собой очередной источник багов, т.к. ожидания программистов и действия компилятора могут не совпадать. На месте разработчиков Java 1.6 я бы держал подобную фичу в большом секрете.
Данная фича никак не может быть источником багов, так как она прозрачна для программиста. Программист никогда не узнает, что объекты размещены в стеке. Первая попытка получить указатель из вне метода приведет к тому, что объект станет размещаться в хипе.
Вот только эта фича не обещает появления ни диструкторов, ни даже using-а. Так что причем тут этот аргумент не понятно.
Это всего лишь оптимизация компилятора. Очень мощьная оптимизация. Но боюсь он ее будет делать редко. А так отличная фича.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, n0name2, Вы писали:
N>>в том то и дело что в строго типизированной и безопасной системе можно безболезненно делать очень радикальные оптимизации в т.ч. на основе статистики собранной в рантайме. это же не C где можно делать арифметические операции над указателями... WH>Только тут надо иметь в виду что стек не резиновый...
Дык они ведь не идеоты. Выделение больших массивов в стеке ко всему прочему снизит эффективность. Ведь весь кайф стэка в том, что он почти все время лежит в кэше процессора. А многокилобайтные массивы быстро свидут на нет это приемущество.
Скорее всего они будут применять некоторые эвристики типа размещаем на стеке только отдельные объекты не и массивы малого размера.
Ну, и не забывай, что в управляемой среде нет проблем с перемещением стека в другой сегмент памяти. Ведь все ссылки можно перестроить! Занимаем, если что, стэк в 10 метров, переносим содержимое старого в него, а старый грохаем. Лафа, блин! Но только если все на 100% управляемое. Один неуправляемый стэковый фрэйм и каюк. А в дотнете это явление очень частое. Так что возможно тут у Явы будет даже приемущество. Хотя опять же JNI приводит к такому же приплызду.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
WH>>Только тут надо иметь в виду что стек не резиновый... GZ>Ага, и то что запросить информацию об объекте и выполнить действия могут через внешний интерфейс типа reflection.
. Они не каждый объект на стэк будут помещать. Это будет делаться только если на объект нет никаких других ссылок. Там применяется мудреный анализ и при первом же подазрении на вшивость бубику в конуре отказывают.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
N>>в общем да — ну так рантайм знает в точности сколько что занимает и совершенно свободно посчитает сколько туда можно пихать. WH>Вот только может возникнуть проблема с рекурсивными алгоритмами которые безпроблем выполнялись на предыдущем рантайме, а в новом будут вываливаться по StackOverflowException. WH>Вобщем тут не все так однозначно.
Ну, ты их за лохов то не держи. Рекурсия будет первым признаком того, что ничего больше 10 байт на стэк помещать не надо.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Я подозреваю, что в современном мире вызвать StackOverflowException можно только по ошибке. Уж очень там лимит зверский стоит.
Лично наблюдал, как один орел добился рабочего SOE. Правда при этом это был КОМ-объект запускавшийся под управлением MMC-консоли в которой почему-то был подозрительно маленький стэк. Добился он этого как раз размещая на стэке большие массивы больших объектов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pzz, Вы писали: Pzz>>Я не думаю, что в форточках это сделано как-то сильно по-другому. Тем Pzz>>более, что в форточках 1) процесс обычно имеет 2 GB адресного Pzz>>пространства, а не 3, как в линухе 2) в форточках потоками принято Pzz>>пользоваться активно. S>В винде вроде бы мегабайт.
Зависит от настроек линкера для С++. Дотнет же волен делать что хочешь. Даже есть перегруженные конструкторы у Thread вроде:
public Thread(ParameterizedThreadStart start, int maxStackSize);
S> Ну пусть у нас толстая процедура, у которой фрейм стека весит килобайт. Получаем глубины в 1024 вызова. Нет, я конечно верю в то, что и числа Фибоначчи можно рекурсивно вычислять, но черт возьми — зачем? А в обычных случаях рекурсии (типа обхода дерева) такие глубины на практике недостижимы.
Ну, вот быстрая сортировка в вырожденых случаях дает, например.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pzz, Вы писали:
Pzz>Это если ему есть куда. В однопоточной программе места, куда ему расти, Pzz>обычно хоть попой ешь. Но вот в многопоточной программе расти ему Pzz>предстоит только до следующего стека (до стека другого потока). А дотуда Pzz>может быть не так уж и далеко.
А, кстати, что мешает в один прекрасный момент поглядеть, что стэка мало... вставить некую процедуру-заглушку и создать новый стэк? Эта заглушка будет первой функцией в новом стэке. Как только ей передадут управление она востановит указатель стека на старый стек и все дела.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Он таки резиновый, хотя, естественно, и ограничен доступной памятью, в языках, в которых стек это деталь реализации. Например, кадры активации в ST, могут для скорости работы мапится на стек, а при исчерпании такового, "материализоваться" в полноценные объекты и переезжать в кучу, освобождая стековое пространство.
Это если где-нить внизу не попадется неуправляемый стековый фрэйм.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>При чём тут оптимизации? Проблемы будут если объект будет создаваться на стеке и по выходу из метода будет вызываться его файналайзер. Полагаясь на этот факт программист пишет вполне рабочий код. Код работает, через полгода в него вносится небольшое безобидное изменение, благодаря которому компилятор принимает решение не создавать объект на стеке. И понеслась. Да даже не через пол года, через неделю о рабочем отлаженом коде уже начинаешь забывать.
Думаю, наличие финалайзера будет первым признаком того что объект обязан жить в хипе. Там еще целая куча эвристик будет. Просто уверен, что джит и ЖЦ окажутся в этом вопросе куда прозорливее чем 99% программистов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>в Жабе финалайзеры считаются оч дурным тоном и практически нигде не используются. зачем они нужны?
Финалайзеры конечно зло. Но без и ни файлик в ОС не отроешь, и подключение к БД можно проворонить.
Так что самостоятельно их конечно и в дотнете никто особо не клепает, но использовать переодически приходится. Вот только в дотнете они ничего не останавливают. Они вызваются в отдельном потоке.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>А как в задаче своевременного освобождения критичных ресурсов помогают finalizers?
Они спасают от случайных ошибок в 90%. Параллельно читаемый файлик ими закрывать конечно грешно, но вот оставить на них ресурсы вроде соеденения с БД или битмапа какого очень даже можно.
Незнаю как там в Яве, но в дотнете за всеми системными хэндлами следят. Так что наличие большого количества хэндлов автоматом приводит к сборки мусора с последующей финализацией повисших хэндлов.
Как говорится: Если у вас параноя — это еще не означает, что за вами не следят.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>>>try/finally — вот единственно верный и гарантированный способ своевременного закрытия ресурсов. IT>>Точно. И как раз с этим в шарпе дела обстоят гораздо лучше чем в джаве.
N>да ну? и чемже? отсутствием checked exceptions?
Забавно, что ты вошел в разговор на волне борьбы с одним предрассудком и тот час же начал насаждать другие.
Разговор о пользе/вреде checked exceptions наверно стоит перенести в отдельную ветку. Тут они ни причем.
Что же касается слов ИТ, то он говорил о такой удобной вещи как using () и паттерне Dispose на котором он основан. Это в сто раз удобнее чем использование try/finally с ручным закрытием ресурсов. Вот тебе простой пример вот такой код:
using System;
using System.IO;
class Program
{
static void Main()
{
string sourcePath = @"C:\boot.ini";
string destPath = Path.ChangeExtension(sourcePath, ".test");
string line;
using (StreamReader reader = File.OpenText(sourcePath))
using (StreamWriter writer = new StreamWriter(destPath))
while ((line = reader.ReadLine()) != null)
if (line.Contains("=\""))
writer.WriteLine(line);
}
}
если бы небало using-а пришлось бы записывать вот таким безобразным образом:
using System;
using System.IO;
class Program
{
static void Main()
{
string sourcePath = @"C:\boot.ini";
string destPath = Path.ChangeExtension(sourcePath, ".test");
string line;
StreamReader reader = null;
StreamWriter writer = null;
try
{
reader = File.OpenText(sourcePath);
writer = new StreamWriter(destPath);
while ((line = reader.ReadLine()) != null)
if (line.Contains("=\""))
writer.WriteLine(line);
}
finally
{
if (reader != null)
reader.Close();
if (writer != null)
writer.Close();
}
}
}
То есть, большая часть кода превращается в синтаксический оверхэд. И это еще есть try/finally, а вот в Обероне и того нет. Лучший, блин, язык все времен и народов.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Но на время отдельных фаз (в зависимости от режима) GC все потоки приостанавливаются,
Они и так останавливаются. Таковы алгоритмы на сегодны.
ПК>и Finalize определенно замедляет GC.
Они способствуют переносу объектов в первое/второе поколение. Вызов финалайзера мало чем отличается от вызова виртуального метода. Просто затраты на регистрацию/дерегистрацию и вызов финалайзера намного больше чем просто созодать объекто а забыть про него. Но делая тоже самое вручную ты получишь примерно такой же оверхэд.
К тому же грамотно написанныйе обертки совмещаются финалайзеры с диспозами которые вынимают объекты из очереди финализации. Тем самым объекты никуда не продвигаются и разбираться с ними очереди финализации не нужно отдельно не нужно. Зато имеем подстраховку в том смысле, что некритичные хэндлы умрут даже если о них забл программист.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, IT, Вы писали:
IT>>В .NET файналайзеры выполняются в отдельном потоке, так что ничего останавливать не надо.
N>даже если бы это было полностью верно, никто не гарантирует что, скажем, незакрытый File подберется в течении ближайших суток (если он вдруг успел запромоутится в permanent generation). ЖЦ это только средство управления памятью а не системными ресурсами. не надо его юзать для того, для чего он не предназначен изначально.
Ну, суток, конечно карантировано. Если только вообще в приложении ничего не делать. Другое дело, что файл такой ресурс, что и пары минут может оказаться достаточным чтобы кто-то нарвался на его блокировку (например, тот же поток). Так что файлы нужно пасти акуратнее.
Но файл ресурс довольно особенный. С другими таких проблем обычно не бывает. Так потеря битмапа — это для NT фактически поретя занимаемой им памяти. Точно так же потеря соеденения с БД из пула не является проблемой. Когда соеденения закончатся можно собрать мусор и получить все потери обратно.
Так что не так уж бесполезны финализаторы. И уж точно они не вредны если не начинать строить логику на финализаторах. В общем, конечно лучше незабывать освобождать ресурсы вручную. Тому особо способствуют конструкции вроде using-а. Но финализаторы это та страховка которая позволит в большинстве случаев приложению работать, а не вылетать при малейшей ошибке.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, reductor, Вы писали:
R>В окамле это давно работает R>Посколько внутри камл-программы мы вообще не видим никакого стека, ни регистров ничего такого, то компилятор этим нагло пользуется и раскидывает данные так, как ему удобно R>за 15 лет ничего не сломалось R>да не только окамл, большинство ML-компиляторов, Clean и Haskell так делают R>теперь вот до Жабы на третьи сутки дошло
О! Вот и функциональщики подтянулись.
ЗЫ
Только не оверквоть, плиз.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вот если пересоздавать те же шрифты при отрисовке каждой ячейке в гриде, то без проблем можно нарваться на тормоза и на современных компьютерах. Но это как правило в сотни, а то и тысячи раз большие потери нежели уничтожение кэша после отрисовки. 
