Сборка мусора

[captain cobalt]

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

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

Более того, сумма накладных расходов на вызов процедуры явного освобождения может запросто стать сопоставимой со временем работы сборщика мусора.

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

[Advertiser]

[Vitamin]

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

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

Более того, сумма накладных расходов на вызов процедуры явного освобождения может запросто стать сопоставимой со временем работы сборщика мусора.

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

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

со сборщиком:
на N блоков памяти имеем N вызовов освобождения, N указателей на блоки, N коррекций этих указателей, М просмотров цепочек (при периодической проверке живых блоков)

что быстрее?

[captain cobalt]

ты забыл о спектрумовской структуре памяти. забыл о том что одновременно адресовать можно только 64 кило и не больше. причем из них приложению принадлежит максимум 16. или ты думаешь что 16 кило нижней памяти хватит на кучу для системы и для всех процессов? сильно в этом сомневаюсь.... да и к тому же защищенность практически никакая в таком случае

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

А что? Делать кучи по одной странице 16К? Кучки. И нельзя в одной куче иметь указатель на блок в другой? Мне не нравится.

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

Здесь уже пошла зависимость от реализации. Но как минимум CALL и RET никуда не денутся.

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

А также, при ошибках программирования, утечку памяти и висящие указатели.

со сборщиком:
на N блоков памяти имеем N вызовов освобождения

Откуда вызовы освобождения?

N указателей на блоки

Традиционный распределитель не будет отслеживать корректность освобождаемого указателя? Значит, будем получать крушение всей кучи при попытке повторного освобождения одного указателя.

N коррекций этих указателей, М просмотров цепочек (при периодической проверке живых блоков)

И освобождение от указанных недостатков ручного освобождения - возможность более лёгкого построения более сложных программных систем.

что быстрее?

Это не всегда абсолютный приоритет.

[Vitamin]

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

А что? Делать кучи по одной странице 16К? Кучки. И нельзя в одной куче иметь указатель на блок в другой? Мне не нравится.

почитай соседний тред. куча для того и нужна чтоб ее адресовать и юзать непосредственно в прямых адресах. верхняя память достукивается через менеджер и там сборщик мусора работает на уровне "сдох процесс- освобождаем память".

Здесь уже пошла зависимость от реализации. Но как минимум CALL и RET никуда не денутся.

а куда они деваются при сборщике?

А также, при ошибках программирования, утечку памяти и висящие указатели.

хех. забудем обнулить указатель для сборщика и у нас тоже чета откудато потечет %)

Откуда вызовы освобождения?

ну сборщик их же вызывает чтобы освободить неиспользуемые блоки

Традиционный распределитель не будет отслеживать корректность освобождаемого указателя? Значит, будем получать крушение всей кучи при попытке повторного освобождения одного указателя.

а если будет?

Это не всегда абсолютный приоритет.

в условиях жестокой ограниченности процессорных ресурсов это один из абсолютных приоритетов

[captain cobalt]

почитай соседний тред. куча для того и нужна чтоб ее адресовать и юзать непосредственно в прямых адресах. верхняя память достукивается через менеджер и там сборщик мусора работает на уровне "сдох процесс- освобождаем память".

Данных должно быть больше чем кода. В том числе потому, что данные могут выступать как код (например, мегакод). Поэтому должна быть возможность манипулирования большими объёмами данных без их копирования.

а куда они деваются при сборщике?
...
ну сборщик их же вызывает чтобы освободить неиспользуемые блоки

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

хех. забудем обнулить указатель для сборщика и у нас тоже чета откудато потечет %)

Однако, со сборщиком мусора практически невозможно ненамеренно добиться, чтобы память систематически утекала (всё больше и больше). Обычно самое худшее - это необнулённый указатель будет удерживать некоторое постоянное количество памяти.

а если будет?

Значит ему тоже понадобится дополнительная память.

в условиях жестокой ограниченности процессорных ресурсов это один из абсолютных приоритетов

Опять же, весь вопрос, каков баланс. Будет ли сборщик мусора в два раза медленнее? Или только на 20%? Умозрительно это точно не оценить.

[Vitamin]

Данных должно быть больше чем кода. В том числе потому, что данные могут выступать как код (например, мегакод). Поэтому должна быть возможность манипулирования большими объёмами данных без их копирования.

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

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

предположим. разумеется, что цикл будет короче чем освобождение всех блоков. при периодичной проверке выигрыш будет или нет?

Однако, со сборщиком мусора практически невозможно ненамеренно добиться, чтобы память систематически утекала (всё больше и больше). Обычно самое худшее - это необнулённый указатель будет удерживать некоторое постоянное количество памяти.

в контексте "забыл убрать- начались потери" оба метода абсолютно равнозначны. потому что можно постоянно выделять блоки и забывать обнулять указатели и память будет именно систематически утекать. все больше и больше...

Значит ему тоже понадобится дополнительная память.

не факт. просто проверяем- принадлежит ли освобождаемая память свободному блоку. с чем может быть проблема- это контроль на правильность длин освобождаемых блоков (выделили столько а освобождаем другой объем).

Опять же, весь вопрос, каков баланс. Будет ли сборщик мусора в два раза медленнее? Или только на 20%? Умозрительно это точно не оценить.

прошу к ассемблеру! %)
то, что на системном уровне сборщик будет только на уровне процессов- однозначно. а вот менеджер кучи может быть ЛЮБЫМ. в том числе и со сборщиком. хотя бы потому что спецификация на большинство ЯВУ требует наличия функции освобождения памяти, а в сборщике такого нет. как говорится, убрать мы всегда сумеем!

[captain cobalt]

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

Без полноценной аппаратной защитной памяти невозможно полноценно реализовать архитектуру юниксов. Значит, следует смотреть в сторону других архитектур операционных систем.

предположим. разумеется, что цикл будет короче чем освобождение всех блоков. при периодичной проверке выигрыш будет или нет?

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

в контексте "забыл убрать- начались потери" оба метода абсолютно равнозначны. потому что можно постоянно выделять блоки и забывать обнулять указатели и память будет именно систематически утекать. все больше и больше...

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

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

не факт. просто проверяем- принадлежит ли освобождаемая память свободному блоку. с чем может быть проблема- это контроль на правильность длин освобождаемых блоков (выделили столько а освобождаем другой объем).

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

то, что на системном уровне сборщик будет только на уровне процессов- однозначно.

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

а вот менеджер кучи может быть ЛЮБЫМ. в том числе и со сборщиком.

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

хотя бы потому что спецификация на большинство ЯВУ требует наличия функции освобождения памяти

Так ведь у нас пока не так уж много реализовано этих самых ЯВУ.

а в сборщике такого нет. как говорится, убрать мы всегда сумеем!

Можно сначала сделать, а потом убрать, а можно сразу сделать сборщик мусора. Тогда и делать а потом убирать ничего не придётся.

[random]

Без полноценной аппаратной защитной памяти невозможно полноценно реализовать архитектуру юниксов. Значит, следует смотреть в сторону других архитектур операционных систем.

вы сами поправитесь или вас опозорить прилюдно? =)

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

[Vitamin]

Без полноценной аппаратной защитной памяти невозможно полноценно реализовать архитектуру юниксов. Значит, следует смотреть в сторону других архитектур операционных систем.

а никто и не говорит что необходимо полностью передирать архитектуру юниксов. кста, есть их реализации и на машинах без аппаратной защиты. в качестве прикола приведу цитату из текстика "ОСи как сортиры" %)

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

так что считай, что у нас стенки подняты )

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

поэтому его надо как минимум делать прицепным а не обязательным и единственным.

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

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

См. выше. Сборщик мусора вообще может располагаться ниже, чем планировщик процессов.

поясни. куда ниже и куда выше

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

поэтому НЕ НАДО его пихать в системный уровень как обязательную часть.

Так ведь у нас пока не так уж много реализовано этих самых ЯВУ.

ну а своим предложением обязательности сборщика ты вообще лишаешь надежды поддержать часть стандартизованных ЯВУ, реализация которых наиболее вероятна.

Можно сначала сделать, а потом убрать, а можно сразу сделать сборщик мусора. Тогда и делать а потом убирать ничего не придётся.

ты повернул все обратно ))
я говорил насчет процедуры освобождения блока. ее мы всегда успеем убрать. главное чтоб она была в рамках стандартного спискового менеджера кучи

[captain cobalt]

вы сами поправитесь или вас опозорить прилюдно? =)

А в чём должно заключаться опозоривание? В том что

юниксов. кста, есть их реализации и на машинах без аппаратной защиты.

?

приехали
два основных типа ошибок связанных с работой с памятью это:
1. забыли освободить память

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

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

Таким образом, со сборщиком мусора, проблема "забыли освободить память" существует в форме "забыли избавиться от всех указателей на ненужную память". Однако, и без сборщика мусора также необходимо избавляться от указателей на ненужную память. Если их сохранять, то возникнет опасность попытки обращения к ним.

Итак, сборщик мусора превращает ошибку программирования "обращение к освобождённой памяти" в менее опасную ошибку "утечка памяти". Однако, это в любом случае ошибка. Сборщик мусора не виноват.

2. обратились к уже освобожденной памяти

Чтобы обратиться к памяти нужно иметь указатель на неё. Сборщик мусора должен знать обо всех указателях. Если существует указатель на память, то сборщик не будет освобождать её.

сборка мусора предназначена для того чтобы подобных ошибок не было. ты предлагаешь сборку мусора (т.е. кучу дополнительного кода) которая от этих ошибок не защищает. тогда какой от нее толк?

Всё-таки во многих случаях защищает.

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

Осталось только где-то взять компилятор C++ -> Z80.

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

Может кто расписать на пальцах как это всё чудище будет работать ?

Это лучше всё-таки посмотреть в учебнике. Или в интернете. Там и картинки есть.

Вот надо мне не 200 байт, а скажем 70 килобайт для игры. И чтоб на прерываниях мизер системы. И чтоб оба экрана юзать... Да хрен с ним, хоть один, основной. И понятно, что не где попало память нужна... короче КАК это всё будет выглядеть реально ?

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

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

Впрочем, это низкоуроневые вопросы, и совсем не имеют отношения к сборщику мусора. Лучше этот вопрос задать тому, у кого кучи по 16К.

поэтому его надо как минимум делать прицепным а не обязательным и единственным.

Надо делать обязательным.

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

Вот именно. Для возникновения утечки недостаточно просто выделять память. Необходимо ещё потрудиться "обеспечить" каждый блок живым указателем на него.

Ситуации же вроде

NEW(p);
NEW(p);

и все их вариации легко разрешаются сборщиком мусора.

поясни. куда ниже и куда выше

Планировщик процессов выделяет себе для работы память используя нижележащий распределитель памяти со сборщиком мусора.

поэтому НЕ НАДО его пихать в системный уровень как обязательную часть.

Но сборщик мусора эффективнее в некоторых ситуациях - в ситуациях, когда он вообще не вызывается. Но готов всегда придти на помощь.

ну а своим предложением обязательности сборщика ты вообще лишаешь надежды поддержать часть стандартизованных ЯВУ, реализация которых наиболее вероятна.

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