Здравствуйте, WolfHound, Вы писали:
AVC>>И как же нам "зацепить" граф объектов за стек или статические переменные? WH>ГЦ обыкновенный. Такойже как и везде. И валистся аналогично. А под словом зацепить за стек или статическую переменную я имел в виду что на стеке или в качастве статичекой переменной делаем указатель и присваиваем ему указатель на один из объектов графа объектов(которые ссылаются друг на друга) WH>А теперь забываем исделать AVC>>3) p := NIL; указатель никуда больше не указывает. WH>Все! Граф будет жить вечно. И такие ошибки уже были например в RSDN@Home(та софтина в которой я пишу этот пост) Да да утечки памяти в программе с ГЦ это реальность.
Какой у Вас несчастный опыт борьбы с GC!
Мне Вас искренне жаль!
Но открою Вам один секрет.
Я ведь тоже человек "дотошный".
Задолго до этой нашей переписки я, с целью проверить Оберон (стоит ли тратить на него свои силы), многократно проделывал самые разные эксперименты.
"Шалил".
В том числе "забывал" присвоить NIL локальному указателю.
Затем запускал GC и проверял состояние кучи.
Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
В отладчике смотрел, отводится ли повторно "потерянная" память.
Так что Ваше убеждение в том, что "граф будет жить вечно" — ложно.
По крайней мере, в отношении Оберона.
Раз у Вас такие проблемы с GC, переходите на Оберон! Там их нет!
WH>А про утечки внешних ресурсов я вобще молчу...
И правильно! И про это Вам тоже лучше пока помолчать, пока не попробовали лично.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Насколько я понял, в Обероне каждый модуль может быть загружен только один раз. Соответственно, мне кажется, что будут проблемы из разряда того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту возможность у всех остальных пользователей...
На атомных станциях не запускают Фотошопов.
Ибо дорого.
Хинт: Оберон-системы не для простых пользователей PC.
Здравствуйте, AVC, Вы писали:
AVC>>Вот если бы я признавался в любви к Си++, да еще с такой же абсурдной мотивировкой, как... AVC>...Зверек Харьковский со своей статьей "C++ulture".
С одной стороны. А с другой — это единственная разумная формулировка для теплого отношения к языку программирования.
Любить некий язык можно только потому, что ты его любишь. По прагматическим соображениям его можно использовать, считать приемлемым для некоторого круга задач — а любовь чувство иррациональное.
Поэтому с той статьей никто и не спорил (практически. А те, кто спорили, выглядели странно)
Ну и почти по теме ветки (чтоб совсем в оффтоп не скатываться): хотел выразить свой респект господину AVC (даже несмотря на то, что он меня слегка обгадил ) — в отличие от топиков СГ (особенно в Первую Оберонову Войну) — они заставляют прислушиваться. Поскольку звучат разумно и доказательно — в отличие от некоторых присутствующих, чьи топики явно несут в себе память участия в Антиобероновом Сопротивлении. Заметьте, что "в прошлый раз" именно Обероново Воинство выглядело в стиле "ЛапыПрочьОтКрутейшегоЯзыка, НеХватаетОпытаНеСуйтесь, ИдитеЧитайтеFМануал" и т.д. — их просто не хотелось слушать. А в этот раз почему-то флаг "ИдитеНафик" перехватили антиобероновцы. И это печально.
AVC>Оберон используется в космической (NASA и т.д.), авиационной (Boeing и т.д.), сферах, сфере атомной энергетики, где ответственность весьма высока. Т.е. используется в тех сферах, где применение Си/Си++ зачастую просто запрещено.
Гы-ы-ы, уже представляю себе топик: ObronOS vs QNX
DJ KARIES,
> ПК>Насколько я понял, в Обероне каждый модуль может быть загружен только один раз. Соответственно, мне кажется, что будут проблемы из разряда того, что Вася, загрузивший модуль Photoshop, тем самым отобрал эту возможность у всех остальных пользователей...
> На атомных станциях не запускают Фотошопов. > Ибо дорого. > > Хинт: Оберон-системы не для простых пользователей PC.
Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, AVC, Вы писали:
AVC>Затем запускал GC и проверял состояние кучи. AVC>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
Вах-вах, как любопытно. То есть GC взял да и прибил объект, на который остались живые ссылки?
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Дык, в такой постановке я согласился с аналогичным тезисом, высказанным AVC еще в прошлой инкарнации данного флейма, уже давно. Речь идет о том, что некоторые особо горячие поклонники Оберонов продолжают настаивать на общей применимости замены разделения памяти и пр. встроенными в язык проверками...
Я бы сказал немного по другому — в определенной (очень узкой) области такая замена приемлема.
Для десктопа и уж тем более серьезных серверных приложений падение безопасности будем неприемлемым, а вот для встроенных устройств и прочих девайсов с ограниченными ресурсами — в самый раз.
Так что прямой конкурент для ОберонОС — это не Windows и Linux, а Symbian. Надо признать, что и здесь googlewar показывает разгромное поражение Оберона: http://googlewar.com/search.cfm?q1=Oberon+OS&q2=Symbian
Или все-таки у него есть какие-то преимущества?
Здравствуйте, AVC, Вы писали:
AVC>Какой у Вас несчастный опыт борьбы с GC! AVC>Мне Вас искренне жаль!
А мне вас по скольку вы досихпор не поняли что ГЦ не панацея. AVC>Но открою Вам один секрет. AVC>Я ведь тоже человек "дотошный". AVC>Задолго до этой нашей переписки я, с целью проверить Оберон (стоит ли тратить на него свои силы), многократно проделывал самые разные эксперименты. AVC>"Шалил". AVC>В том числе "забывал" присвоить NIL локальному указателю. AVC>Затем запускал GC и проверял состояние кучи. AVC>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC.
Значит плохо проверял.
Пишу на C# думаю на оберон переведешь сам.(не компилил так что могут быть опечатки)
Левый модуль(заметь никаких "опасных конструкций", ничего не импортирует и тем не мение... )
public class BadClass
{
public BadClass(object o)
{
CollectTrash(o);
CollectTrash(this);
}
public void BadMethod(object o)
{
CollectTrash(o);
}
public void ReleaseTrash()
{
collect_trash_here = null;
}
class List
{
public object trash;
public List next;
}
static List collect_trash_here = null;
void CollectTrash(object o)
{
List trash = new List();
trash.trash = o;
trash.next = collect_trash_here;
collect_trash_here = trash;
}
}
Надеюсь теперь до тебя дошло что я пытался сказать? Если посоздавать объекты класса BadClass педергать у них метод BadMethod и забыть дернуть ReleaseTrash то мусор будет жить вечно...
Запомни ГЦ всеголишь алгоритм который завалить чуть сложнее чем банальный подсчет сылок. Но можно. Ибо ни один алгоритм не сможет предсказать все ошибки человека. Это не возможно.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
AVC пишет:
> В том числе "забывал" присвоить NIL локальному указателю. > Затем запускал GC и проверял состояние кучи. > Все "безнадежно потерянные", по Вашему убеждению, объекты > "подбирались" GC.
Эххх...
==============================
List list=new ArrayList();
while(true)
{
list.add(new String("Blah-blah"));
}
==============================
Аналог этого кода на Обероне оставляю в качестве упражнения читателю.
GC никогда не соберет список, так как он не является мусором.
Здравствуйте, Cyberax, Вы писали:
C>============================== C>List list=new ArrayList(); C>while(true) C>{ C> list.add(new String("Blah-blah")); C>} C>============================== C>Аналог этого кода на Обероне оставляю в качестве упражнения читателю.
C>GC никогда не соберет список, так как он не является мусором.
Вы сделали ошибку под названием "бесконечный цикл". При чем тут GC? Или Вы полагаете, что без него этот код вдруг перестанет содержать ошибку бесконечного цикла?
Вот корректный код:
PROCEDURE Do (N: INTEGER);
VAR list: List; i: INTEGER;
BEGIN
NEW(list);
FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END
END Do;
Не смотря на то что переменная list располагается на стеке, и, в придачу, при завершении процедуры не производится явного присваивания list := NIL; GC все равно освободит всю память занимаемую списком.
Здравствуйте, WolfHound, Вы писали:
WH> Надеюсь теперь до тебя дошло что я пытался сказать?
А при чем тут GC? Или Вы полагаете что его отсутствие вдруг волшебным образом исправит допущенную Вами ошибку?
С другой стороны, а что если GC отсутствует, в указателе collect_trash_here хранится некое ненулевое значение, и что дальше?
Вы сделаете:
1) самостоятельно очистите память и обнулите указатель collect_trash_here (а вдруг его значение кто-то скопировал?)
2) самостоятельно очистите память и забудете обнулить указатель collect_trash_here (повисшая ссылка)
3) просто обнулите указатель collect_trash_here забыв освободить память (утечка памяти)
4) забудете и то и другое
Все эти пункты являются ошибочными за исключением случая (1) при условии что больше никто не получал информации об collect_trash_here (так как информация становится более недействительной — у кого-то повисает указатель). Все это приводит к краху системы.
В случае же наличия GC система не падает, а просто ест память, но рано или поздно переменная collect_trash_here все равно может быть обнулена и память будет возвращена, в то время как без GC утекшая память — утекла навсегда.
Здравствуйте, Дарней, Вы писали:
AVC>>Затем запускал GC и проверял состояние кучи. AVC>>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC. Д>Вах-вах, как любопытно. То есть GC взял да и прибил объект, на который остались живые ссылки?
Вовсе нет!
WolfHound говорил о стековом указателе (т.к. хотел "зацепить граф объектов за стек".)
Представим себе какой-нибудь код вроде:
PROCEDURE SapientiSat;
VAR p: PointerToVeryBigObject; (* Локальный указатель; находится в стеке *)BEGIN
NEW(p);
... (* много полезного кода с этим p :) *)
(* а здесь я забыл вставить оператор p := NIL *)END SapientiSat;
Видите сами, что указатель p более не существует.
Т.е. это "мертвая" ссылка.
По мысли WolfHound, "граф будет жить вечно". (Как Дракула. )
Но в Обероне все работает правильно.
Более того, если я все-таки вставляю в конец процедуры злосчастный оператор
p := NIL
то некоторые компиляторы Оберона его просто удаляют как излишний, с беззлобными ругательствами вроде:
eliminatining redundant code
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Сергей Губанов пишет:
> C>============================== > C>List list=new ArrayList(); > C>while(true) > C>{ > C> list.add(new String("Blah-blah")); > C>} > C>============================== > C>Аналог этого кода на Обероне оставляю в качестве упражнения читателю. > C>GC никогда не соберет список, так как он не является мусором. > Вы сделали ошибку под названием "бесконечный цикл". При чем тут GC? > Или Вы полагаете, что без него этот код вдруг перестанет содержать > ошибку бесконечного цикла?
И что? С каких это пор бесконечный цикл стал ошибкой?
> Вот корректный код: > >PROCEDURE Do (N: INTEGER); >VAR list: List; i: INTEGER; >BEGIN > NEW(list); > FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END >END Do; > > > Не смотря на то что переменная list располагается на стеке, и, в > придачу, при завершении процедуры не производится явного присваивания > list := NIL; GC все равно освободит всю память занимаемую списком.
И пусть N=2^64.
Будет точно то же самое — утечка памяти до ее полного переполнения.
Сергей Губанов пишет:
> WH> Надеюсь теперь до тебя дошло что я пытался сказать? > А при чем тут GC? Или Вы полагаете что его отсутствие вдруг волшебным > образом исправит допущенную Вами ошибку?
Нет, это мы пытаемся сказать, что уровня изоляции OberonOS не хватит
даже для самых простых случаев.
Здравствуйте, Cyberax, Вы писали:
>> Вот корректный код: >> >>PROCEDURE Do (N: INTEGER); >>VAR list: List; i: INTEGER; >>BEGIN >> NEW(list); >> FOR i := 1 TO N DO list.add(NewString("Blah-blah")) END >>END Do; >> >>
C>И пусть N=2^64.
C>Будет точно то же самое — утечка памяти до ее полного переполнения.
Ммм. А где собственно утечка?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, WolfHound, Вы писали:
AVC>>Какой у Вас несчастный опыт борьбы с GC! AVC>>Мне Вас искренне жаль! WH>А мне вас по скольку вы досихпор не поняли что ГЦ не панацея.
Конечно, GC — не панацея.
Я никогда и не утверждал обратного.
GC — это просто удобный и мощный инструмент.
Не более, но и не менее.
В Обероне (не пользуясь низкоуровневыми средствами) "завалить" грамотно написанный GC невозможно. Его нельзя "зацепить" ни за стек, ни за статическую переменную, вопреки Вашему утверждению. (Помните, как странно раньше казалось, что в первоначальном, "виртовском", Паскале указатель мог указывать только на объект в куче. Ан, нет. Вовсе не глупость! Хотя и не получило тогда развития.)
Конечно, GC отвечает только за определенные свойства системы, а за все отвечать не может.
"Исчерпание" памяти, например, не является ошибкой GC и не ведет к его "убийству".
С ним надо бороться другими (системными) средствами: квотами, виртуальной памятью и т.д.
AVC>>Все "безнадежно потерянные", по Вашему убеждению, объекты "подбирались" GC. WH>Значит плохо проверял. WH>Пишу на C# думаю на оберон переведешь сам.(не компилил так что могут быть опечатки) WH>Левый модуль(заметь никаких "опасных конструкций", ничего не импортирует и тем не мение... ) WH>
WH>public class BadClass
WH>{
WH> public BadClass(object o)
WH> {
WH> CollectTrash(o);
WH> CollectTrash(this);
WH> }
WH> public void BadMethod(object o)
WH> {
WH> CollectTrash(o);
WH> }
WH> public void ReleaseTrash()
WH> {
WH> collect_trash_here = null;
WH> }
WH> class List
WH> {
WH> public object trash;
WH> public List next;
WH> }
WH> static List collect_trash_here = null;
WH> void CollectTrash(object o)
WH> {
WH> List trash = new List();
WH> trash.trash = o;
WH> trash.next = collect_trash_here;
WH> collect_trash_here = trash;
WH> }
WH>}
WH>
WH>Надеюсь теперь до тебя дошло что я пытался сказать? Если посоздавать объекты класса BadClass педергать у них метод BadMethod и забыть дернуть ReleaseTrash то мусор будет жить вечно...
Это уже не является ошибкой GC и не ведет к его падению.
Я так понял, от идеи "завалить" GC, "зацепив" его за стек, Вы уже отказались.
WH>Запомни ГЦ всеголишь алгоритм который завалить чуть сложнее чем банальный подсчет сылок. Но можно. Ибо ни один алгоритм не сможет предсказать все ошибки человека. Это не возможно.
Ни один алгоритм и не обязан этого делать.
Для корректности работы алгоритма достаточно поддерживать только некоторые свойства.
Грамотно написанный GC на это способен, и его "уронить" нельзя.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>По мысли WolfHound, "граф будет жить вечно". (Как Дракула. ) AVC>Но в Обероне все работает правильно.
Само собой, что и в CLR тоже — я не думал, что кому-то здесь этот факт неизвестен. Скорее всего, имелась в виду переменная, которая долгое время находится в области видимости (ну например локальная переменная функции-точки входа программы)
)
