Вид для печати
Здесь имеет место другое: подразумевается что указанный ЯВУ работает поверх нормальной системы.Цитата:
Сообщение от random
А тогда сам вопрос отпадает.
С другой стороны, если считать что в этом смысле ЯВУ заменяет собой систему, то получается ещё лучше: вариации на тему "хотел написать оболочку, написал ОСь"
Сборщик мусора должен иметь информацию обо всех указателях. В том числе находящихся внутри объектов. При работе он ищет все достижимые через указатели объекты, в том числе через цепочки указателей внутри объектов.Цитата:
Сообщение от elf/2
Таким образом, корректная сборка мусора возможна.
ближе к коду:Цитата:
Сообщение от captain cobalt
1. мы попросили у системы 100 байт
2. нам вернули указатель на выделенную память в регистре HL
3. это был временный буфер, мы его использовали и он нам больше не нужен
что мы должны сделать дальше чтобы сборщик мусора понял что эту память можно забирать?
указатели должны быть типизированы или каждый блок памяти иметь маркер типа или размера блокаЦитата:
Сообщение от elf/2
Для упрощения конструкции лучше, чтобы все указатели находились в памяти, то есть в данном случае нужно чтобы либо сразу после этого выделения HL сразу атомарно записывался в память, где его найдёт сборщик мусора, либо чтобы функция выделения памяти сама записывала указатель в память.Цитата:
Сообщение от elf/2
Блок памяти определяется как мусор, когда при следующем запуске сборщика мусора он определяет что блок не является достижимым по цепочкам указателей начиная с глобальных статических указателей.
указанные языки хранятся в памяти в виде байт-кода. а выполнением занимается виртуальная машина. очистка неиспользуемой памяти идет отдельным потоком (т.е. как минимум нужна многозадачность). плюс к тому, очистка происходит в несколько этапов, т.н. поколений. если блок памяти не выдержал проверки, он убивается. реализация данного дела довольно сложна, поэтому должна быть не частью ОС, а частью реализации ЯВУ (если таковые будут), потому как автоматическая сборка мусора довольно ресурсоемкое занятие.Цитата:
Сообщение от captain cobalt
для написания программ на ЯВУ- это сплошное удовольствие. а представь каково это на асме? двойная адресация (адресуем ячейку, в которой хранится адрес выделенного блока памяти) будет замедлять и без того невысокую скорость работы программ. плюс трата системных ресурсов на периодическую проверку и сборку этого мусора.Цитата:
Сообщение от captain cobalt
скажу за себя (и это мое глубочайшее IMHO)- языки без автоматической сборки мусора более дисциплинируют- программист сам несет ответственность за эффективность использования памяти (зачастую более высокую, чем у сборщика). а что касается памяти процесса- то она конечно очищается после того как процесс прекратил свое существование. если работа процесса разовая, то об очистке беспокоиться не надо- все уберется потом. но для "долгоиграющих" процессов надо заботиться об очисткеЦитата:
Сообщение от captain cobalt
А как насчет скорости ?
Ну, на спеке так не развернешься, как пишут... В любом случае кодер знает сколько памяти сожрет его прога. Значит и в запросах можно оперировать реальными числами. Т.е.
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
основа всего- универсальный менеджер кучи, выделяющий память с точностью до байта и работающий по дескриптору кучи (где она начинается и сколько памяти под нее всего). метод реализации- уже тонкости (самый простой- списковый, можно еще какой-нибудь). максимум что может позволить себе этот менеджер- автоматическую дефрагментацию (существуют быстрые методы решения подобных вопросов). освобождение ранее выделенных блоков- исключительно задача процесса-владельца кучи.
для смотрящих в сторону C# и Java, где сабж реализован, замечу, что данные языки являются производными от базового- С/С++, где есть функции как выделения, так и освобождения памяти.