Здравствуйте, Кодт, Вы писали:
К>На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.
Не парится над удалением объектов, а не над тем что оперативная память может быть исчерпана.
Re[11]: Связанные с типом процедуры должны быть виртуальными
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Рантайм нужен (кроме всего прочего) для safety (проверка индексов, динамическое приведение типов, и т.д.), а рантаймовый сборщик мусора нужен для расширяемости. Потому что только во время работы системы можно принять решение об освобождении памяти, но невозможно это сделать во время написания отдельно взятого модуля, когда точно не известно в какой системе он будет запущен на выполнение и кто его будет использовать, какие модули в этот момент будут загружены в систему и т.д.
Достаточно не разбрасываться памятью направо и налево, и тогда половина вопросов снимется.
Например, отсутствие в С++ сборки мусора на уровне языка заставило людей задуматься о таком природном явлении, как политики владения данными. Это больше, чем владение памятью (и не только памятью), на самом деле.
И соответственно, найдены разные способы управления разделяемыми данными:
— выстрелил-и-забыл: требует ответственности с принимающей стороны, зато минимальные накладные расходы и простота синтаксиса (голые указатели), совместимость с разными API.
— передача владения: выстрелил, если там подхватили то молодцы, а если нет, то освободили. Например, std::auto_ptr.
— совместное владение: подсчёт ссылок. Простота реализаций (разных!), небольшие накладные расходы, покрывает изрядную долю потребностей. Есть ряд подводных камней наподобие циклических зависимостей (решаемые, но уже на уровне проектирования!).
— безответственное владение: сборка мусора. Дёшево для программиста (если фича встроена в язык), дорого для системы.
Здравствуйте, Сергей Губанов, Вы писали:
К>>На Обероне такую фигню спороть гораздо легче, чем на С++. Просто хотя бы потому, что программист С++ (и даже, отчасти, на VB6) изначально держит в голове вопросы использования памяти. А Оберон (и другие языки с GC) позволяют ему не париться.
СГ>Не парится над удалением объектов, а не над тем что оперативная память может быть исчерпана.
А это одно и то же, в шаловливых ручках.
Вот пример был:
При том, что имеется встроенный в GDI сборщик неиспользуемых объектов — этот код выжрет все ресурсы со страшной силой.
И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.
Здравствуйте, WolfHound, Вы писали:
WH>ЗЫ Ты уже не первый раз пытаешься ставить под сомнение профпригодность собеседников.
1) Когда Vlad2 заявил что в обероне нет RETURN, хотя он есть, а также что он является мертвым языком, я это опроверг, а Владу сообщил что он не компетентен в этом вопросе. Обратите внимание на слова "в этом вопросе". Никакого сомнения в профпригодности я не выдвигал. (Кстати, совсем недавно Vlad2 стал заявлять что в оберонах, оказывается есть JIT компилятор, которого там на самом деле нет и не понятно с чего он это взял).
2) Малограмотность большинства программистов — это тоже факт. Посмотрите на вопросы задаваемые в технических форумах. Так что ничего особенного в таком заявлении нет.
3) Вы лично привели код якобы тестирующий сборщик мусора, а на самом деле не имеющий к нему никакого отношения. После того как я указал Вам на это, Вы вместо того чтобы признаться в том что совершили ошибку, приводите мне правила поведения на форуме. Как это понимать?
К>При том, что имеется встроенный в GDI сборщик неиспользуемых объектов — этот код выжрет все ресурсы со страшной силой.
А зачем же так сложно? Есть более простой способ:
VAR a: POINTER TO ARRAY OF BYTE;
BEGIN
NEW(a, 1000000000); (* Зажираем 1 гигабайт одним махом *)
К>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.
Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.
Здравствуйте, Сергей Губанов, Вы писали:
К>>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.
СГ>Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.
А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
Здравствуйте, Сергей Губанов, Вы писали:
К>>И я уже говорил про совместное адресное пространство: в пользовательских системах любая корпоративность (будь то адресное пространство, планировка или что ещё) — серьёзная дыра в безопасности. Найдётся один придурок, который угробит деятельность не только своей программы, но и системы в целом.
СГ>Совершенно серьезный вопрос: Как он это сделает? Ведь он не может обратиться к чужой памяти ни для чтения ни для записи, так как в языке программирования нет такого понятия как адресное пространство.
Если нет указателей-то действительно никак. Единственная возможность выход за границы массива. Правда насколько я понял это контроируется в рантайме. Однако идеальных систем не бывает, где выигрываем на системных вызовах серьезно проигрываем на массивах. С одной стороны такой подход (все в режиме ядра) должен дать большие преимущества в многопоточных серверных приложениях, а с другой стороны серверным приложениям нужен доступ к таким штукам как БД, а написать быструю БД на языке не позволяющем делать низкоуровневые оптимизации (прямая работа с памятью, отображение файлов в память и работа с ними как с массивами), имхо малореально. Т.е. получим быстрый многопоточный сервер, но преимущества могут сойти на нет из-за медленой БД. Т.е. как всегда палка о двух концах. Есть правда еще один скользкий вариант разрешить в такой системе низкоуровневое программирование, но даже при тщательном программировании надежность будет уже не та — все сможет рухнуть.
Здравствуйте, Кодт, Вы писали:
К>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, Кодт, Вы писали:
К>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
СГ>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.
И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.
Здравствуйте, Клапауций, Вы писали:
К>>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
СГ>>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.
К>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.
Не говоря уже о том, что нормальные ОС умеют выделять квоты на память и дисковое пространство. Тем самым выводят из-под удара всех остальных процессов.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>3) Вы лично привели код якобы тестирующий сборщик мусора, а на самом деле не имеющий к нему никакого отношения. После того как я указал Вам на это, Вы вместо того чтобы признаться в том что совершили ошибку, приводите мне правила поведения на форуме. Как это понимать?
Где я сказал что тестирую сборщик мусора? Это придумал ты. Это была лишь реакция на твой бред на счет того что в обероне все суперпупер и уронить его нельзя.
ЭТО НЕ ТАК! И именно это продемонстрировал мой пример. В реальных системах так ессно никто писать не будет. Но граф объектов может зацепится за чтонибудь случайно просто по недосмотру. Например в Янусе(он написан на .НЕТ)довольно долго была утечка памяти из-за того что просто не учли что если объект подписывается на событие санглитона то он не будет убран пока не отпишится от события.
Это была банальная ошибка программиста и никакой ГЦ от этого не застрахует.
С янусом то все просто надобыло его иногда переоткрывать(а если не держать его открытым неделями то эту утечку вобще небыло видно), а что делать в оберон-ос в которой один сборщик мусора на всех? А если подобная ошибка будет совершена в по для АЭС?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Как пункт "Обязательные правила" про критическую массу и далее по тексту.
WolfHound привёл пример совершенно реальной ситуации — для того, что бы это проверить достаточно 5 минут. И хотя у меня нет оберона — я уверен что и под ним результат будет тем же самым.
Если он и сделал ошибку — так в том, что пытался сделать класс больше по размеру, а не меньше. Чем класс больше — тем меньше ссылок и устойчивее работает GC, а вот чем меньше — тем больше ссылок придётся разгребать и тем глубже GC задумается...
Здравствуйте, Клапауций, Вы писали:
К>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Здравствуйте, Кодт, Вы писали:
К>>>А вот так: выжрет всю память и начнёт молотить бесконечный цикл. Всё, отдыхаем. В виндах я хотя бы Ctrl+Alt+Del нажму... прибью процесс, который много себе позволяет, и буду щаслив. А здесь?
СГ>>Где здесь? BlackBox, например, под виндой работает — жмите Ctrl+Alt+Del.
К>И что дальше то ? Убить процесс BlackBox ? Так это будет аналогично нажатию ресета в винде, а никак не убиению провинившегося процесса.
С точки зрения самого Windows, система BlackBox — это обычное приложение Windows со всеми вытекающими последствиями... Так что нечему тут удивляться.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Как пункт "Обязательные правила" про критическую массу и далее по тексту. AF>WolfHound привёл пример совершенно реальной ситуации — для того, что бы это проверить достаточно 5 минут. И хотя у меня нет оберона — я уверен что и под ним результат будет тем же самым. AF> Если он и сделал ошибку — так в том, что пытался сделать класс больше по размеру, а не меньше. Чем класс больше — тем меньше ссылок и устойчивее работает GC, а вот чем меньше — тем больше ссылок придётся разгребать и тем глубже GC задумается...
Извините, а что именно Вы проверили? Вы, что, тоже GC проверяли с помощью кода:
Class1 c = null;
while(true)
{
Class1 n = new Class1();
n.next = c;
c = n;
}
А поконкретнее, в каком именно месте тут должен был сработать GC?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>С точки зрения самого Windows, система BlackBox — это обычное приложение Windows со всеми вытекающими последствиями... Так что нечему тут удивляться.
А если это оберон-ос стоящая на АЭС?
... << RSDN@Home 1.1.4 rev. 185 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Где я сказал что тестирую сборщик мусора?
Вот тут:
Этот код конечно не роняет .НЕТ но программа примерно на 9 миллионах итераций уходит в глубокий ГЦ... но из него всеравно не вернется...
<code>
Уверен что на обероне будет тотже результат.
Ты скажешь а какое отношение это имеет к реальным программам? Да очень простое. В реальных программах будет граф ссылок и если этот грав гденибудь недай бог случайно зацепится за стек то произойдет... см код выше.
Нет, ну если, конечно буквы ГЦ — это вовсе не GC — сборщик мусора. То, я не прав. Моя вина. Прости. Но не объяснишь ли что же это за буквы такие — ГЦ?
СГ>Уже проходили. Пример недействительный (я бы так не написал).
Что значит недействительный? Оберон не позволяет так писать? Или всё же твоё мастерство не позволяет?
Ну хорошо. Не ты. Вася Пупкин написал свой модуль и не подумал, что кто-то может использовать его не по назначению.
В Эйфеле — там каждая функция оснащается контрактом. Попытка вызвать percentage(x,y) с нулевым y будет пресечена на шаг раньше.
Если, конечно, программист озаботился тем, чтобы этот контракт правильно написать — что тоже является допущением...
Или пример с янусом — подписка по требованию, а отписка — когда необходимость исчезнет. Как следствие, трупик.
Потому что на встроенный сборщик мусора верит, что эта деталька привинчена, и оставляет её в покое.
Сборка мусора — это не только сервис рантайма, но ещё и Принцип. И воплощать его нужно на всех уровнях, где появляются потребители ресурсов — в том числе на самых верхних. Но туда коротенькие лапки рантайма уже не дотянутся.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>С точки зрения самого Windows, система BlackBox — это обычное приложение Windows со всеми вытекающими последствиями... Так что нечему тут удивляться. WH>А если это оберон-ос стоящая на АЭС?
Ответ на этот вопрос надо искать в мануалах той ОСи, у меня их нет. Так что, прости, я на этот вопрос ответить могу. Может кто другой сможет.
Перекуём баги на фичи!
Уж там он как залезает — так мало никому не покажется... 
