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

[captain cobalt]

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

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

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

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

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

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

а если будет?

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

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

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

[Vitamin]

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

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

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

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

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

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

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

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

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

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

[captain cobalt]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[random]

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

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

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

[elf/2]

как сборщик памяти сможет это понять и вернуть память в систему?

Сборщик мусора знает обо всех указателях. Для того, чтобы "сообщить", что память больше не нужна, нужно в указатель в памяти записать другое значение (например, нулевой указатель - ни на что не указывающий). Когда сборщик мусора при следующем запуске не найдёт живых указателей на блок памяти, он объявит его мусором.

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

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

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

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

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

[Знахарь]

Народ!!!! АУ!!!! Не далеко ль Вы полезли ? шо то я от ваших указателей одурел А как z80 одуреет ?

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

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

[Advertiser]

[Vitamin]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[SfS]

Вставлю свои пять копеек.

Я организовывал в программах, которые много работали с выделением-освобождением памяти следующее:

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

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

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

Таким образом при использовании free(void* ptr) экономится время, поскольку просматривается не весь список, а только элементы, соседние с удаляемым.

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

ИмХО, такой подход более расточителен по памяти, зато много головных болей устраняет.

[captain cobalt]

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NEW(p);
NEW(p);

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

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

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

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

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

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

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

[elf/2]

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

давайте вернемся к истокам...

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

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