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

[GriV]

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

Здесь имеет место другое: подразумевается что указанный ЯВУ работает поверх нормальной системы.
А тогда сам вопрос отпадает.
С другой стороны, если считать что в этом смысле ЯВУ заменяет собой систему, то получается ещё лучше: вариации на тему "хотел написать оболочку, написал ОСь"

[captain cobalt]

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

Сборщик мусора должен иметь информацию обо всех указателях. В том числе находящихся внутри объектов. При работе он ищет все достижимые через указатели объекты, в том числе через цепочки указателей внутри объектов.
Таким образом, корректная сборка мусора возможна.

[elf/2]

Сборщик мусора должен иметь информацию обо всех указателях. В том числе находящихся внутри объектов. При работе он ищет все достижимые через указатели объекты, в том числе через цепочки указателей внутри объектов.
Таким образом, корректная сборка мусора возможна.

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

что мы должны сделать дальше чтобы сборщик мусора понял что эту память можно забирать?

[SMT]

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

что мы должны сделать дальше чтобы сборщик мусора понял что эту память можно забирать?

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

[captain cobalt]

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

что мы должны сделать дальше чтобы сборщик мусора понял что эту память можно забирать?

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

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

[Vitamin]

Сборка мусора - это способ автоматического управления памятью, применяемый в большинстве функциональных языков программирования и в некоторых императивных языках. В том числе в технологиях Java и .NET от известных транснациональных корпораций.

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

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

для написания программ на ЯВУ- это сплошное удовольствие. а представь каково это на асме? двойная адресация (адресуем ячейку, в которой хранится адрес выделенного блока памяти) будет замедлять и без того невысокую скорость работы программ. плюс трата системных ресурсов на периодическую проверку и сборку этого мусора.

Какие будут мнения насчёт обоснованности применения сборщиков мусора в средах исполнения на Speccy?

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

[Advertiser]

[Знахарь]

А как насчет скорости ?

Ну, на спеке так не развернешься, как пишут... В любом случае кодер знает сколько памяти сожрет его прога. Значит и в запросах можно оперировать реальными числами. Т.е.
1. говоришь, что надо тебе 3х16кб страницы.
2. Ось говорит: на и вешает на эти 3 страницы флажок занято. при этом дает тебе номерок
3. говоришь "у меня всё"
и даешь ей номерок и код "у меня всё"
4. ось говорит ОК и снимает флажки занято.

dll

принцип тот же, нужен тебе dll:

1. берешь список процессов (программ/модулей.. как угодно) оси ищешь название/код (версию) dll (а как еще ?)
2.нету такого. Ага. говришь оси нужна еще скжаем страница под эту dll.
3. ось выдает страницу.
4. грузишь dll туда но в список процессов вносишь ее код/ имя.
сам можешь закрываться, dll останется, но!

на таких ресурсах вешать 1 байт - колво пользующихся. Т.е. 1 прога юзает dll -1 ,3 юзают - 3. никто не юзает - 0 но из списка убирать ресурс только тогда, когда его страницу кому-то отдали.

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

Такой вот простой менеджер памяти с уборкой мусора. Ну а теперь как реализовать реально хотя бы такое... И сколько оно будет жрать ресурсов само по себе ?

[Знахарь]

Vitamin! Ты тут? А ну говори, что нибудь по этому поводу! Ты ж этим занимался

[GriV]

Чтобы схема заработала надо лобзиком дрова напилить!

[Vitamin]

Чтобы схема заработала надо лобзиком дрова напилить!

сказал как в лужу пёрднул %)

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

для смотрящих в сторону C# и Java, где сабж реализован, замечу, что данные языки являются производными от базового- С/С++, где есть функции как выделения, так и освобождения памяти.