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

[Vitamin]

Это не годится для динамических связных структур данных.

Вот, кстати, ещё один аргумент за сборщик мусора - что лучше: в каждой программе иметь (рекурсивные) процедуры для уничтожения связных структур данных, или иметь один сборщик мусора?

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

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

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

Ничего не боюсь!
Одна куча на всю систему.
Со сборщиком мусора.
Кому не надо, не использует его.

одна куча на всю систему может быть только в нижней памяти. да и то она принадлежит системе. а у каждого процесса своя куча, которая рулится ЛЮБЫМ менеджером. по умолчанию- системным (без сборщика)

На какую тему?
Сборщик мусора встаёт поперёк дороги каким-то приёмам оптимизации?

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

Можно спроектировать такой интерфейс распределителя памяти, при котором он одновременно записывает адрес в память и загружает в HL. Тогда этот клочок кода превратится в

LD HL,block1
CALL allocate
LD DE,dest
LD BC,len
LDIR

Весьма симпатично.

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

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

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

а насколько ты думаешь будет использоваться "куча" программистами, которые до этого с ней никак не работали? довольно большая часть методов, требующих динамическую память, прекрасно решаются в статической

[Advertiser]

[Vitamin]

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

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

[captain cobalt]

для реализации сборки мусора не нужна многозадачная ось или потоки. никто не мешаеть позвать его автоматически в тот момент когда кончилась память (из системной функции new).

Абсолютно верно.

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

Абсолютно верно.

сборка мусора никак не связана с виртуальными машинами/байткодом. есть библиотеки для C++ реализующие сборку для некоторых частных случаев

Абсолютно верно.

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

Сборщику мусора необходимо сообщить обо всех существующих указателях.

все еще предлагаю решить простейшую задачу:
1. программа попросила 200 байт памяти, вызвав системную функцию new/malloc
2. указатель на блок памяти нам вернули (в HL или записали куда-то еще в память)
3. мы этот блок использовали и он нам больше не нужен

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

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

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

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

Будут полноценные malloc и free - тогда можно и о большем думать...

А можно поднатужиться, и сразу родить сборщик мусора. Тогда и free не понабодится.

[Vitamin]

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

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

[captain cobalt]

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

С третьей стороны, сборщик мусора особо не мешает при "обычном" программировании.

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

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

одна куча на всю систему может быть только в нижней памяти. да и то она принадлежит системе. а у каждого процесса своя куча, которая рулится ЛЮБЫМ менеджером. по умолчанию- системным (без сборщика)

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

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

Да здравствует объединённый распределитель памяти!

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

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

а насколько ты думаешь будет использоваться "куча" программистами, которые до этого с ней никак не работали? довольно большая часть методов, требующих динамическую память, прекрасно решаются в статической

Несомненно.
Но динамическое выделение (распределение) памяти в любом случае понадобится.

[captain cobalt]

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

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

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

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

[Vitamin]

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

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

Но динамическое выделение (распределение) памяти в любом случае понадобится.

с этим никто не спорит. вопрос в освободительской политике %)

[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 никуда не денутся.

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

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

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

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

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

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

а если будет?

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

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