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

[captain cobalt]

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

Нету.

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

Вот именно этот вопрос и хотелось обсудить с самого начала. Применительно к сборке мусора.

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

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

Поэтому здесь ответ зависит от низкоуровневого представления указателя, по поводу чего нет консенсуса среди меня.

[elf/2]

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

у тебя есть идеи как это реализовать на speccy или готовая реализация?

если нет то предлагаю заморозить дискуссию до момента появления как минимум спецификации (от тебя или кого-либо другого)

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

[Vitamin]

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

загляни-ка в интернет (существуют такие специальные сайты-поисковики). вот что мне выдал один из них после пары запросов навскидку:
Inferno - виртуальный пост-Unix в кармане
http://oslab.h11.ru/index.php?mod=art&part=unix&id=001

RT-Linux
http://embedded.ifmo.ru/embedded_old...X/rtlinux.html

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

о каких НИЖНИХ СТРАНИЦАХ ты говоришь? я лично знаю всего ОДНУ машину, на которой можно подставлять страницы в адрес #8000-#bfff. и если уж на то пошло, то 16 кило (а их в НИЖНИХ СТРАНИЦАХ именно столько- 16384 байта по 8 бит каждый) маловато для приложений.
а отводить всю остальную память под кучу, которая не факт что будет использована по меньшей мере нерационально.

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

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

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

вот именно что в НЕКОТОРЫХ, да еще когда он не используется. при этом даже не расходует процессорного времени. блеск! логика обалденная, снимаю шляпу (вместе с джинсами). а нахрена спрашивается тогда его вообще городить, если он будет эффективнее только если не будет вызываться?

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

ты мне назови хотя бы одну ОС, где сборщик мусора реализован на системном уровне. я могу назвать только две (постарайся назвать их и по возможности дополнить список). но скажу сразу- там ВЫДЕЛИТЕЛЬ памяти настолько же сложный насколько и эффективный. и предложенная тобой схема списков выглядит очень бледно %) можешь мне поверить %)

[Vitamin]

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

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

Структура неявного однонаправленного списка:

2 байта - размер выделенной области.
14 Бит - флаг занятости цепочки
15 бит - флаг окончания списка.
(Наибольший размер выделяемой свободной памяти при этом 16384б.)

Выделение памяти:
LD HL,SIZE - размер
CALL ALLOC

Освобождение памяти:
LD HL,ADDR - адрес цепочки
CALL FREE

Можно применить для любой 16Кб области как в основной памяти, так и в страничной.

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

list_descriptor
head dw blk1
tail dw blk3 ;?
lock db 0

...
blk1 dw 0 ;previous==NULL - first one
dw blk2
...
blk2 dw blk1
dw blk3
....
blk3 dw blk2
dw 0 ;next==NULL - last one

вот и все. и хранить флаги начала/конца списка абсолютно не нужно.

пример списка применительно к менеджеру памяти. пустая куча:
head dw heap
tail dw heap
...
heap dw 0
dw 0
dw heap_len

выделили 200 байт. структура будет следующая:

head dw blk1
tail dw blk1
...
heap

;heap+200
blk1 dw 0
dw 0
dw heap_len-200

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

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

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

[captain cobalt]

загляни-ка в интернет (существуют такие специальные сайты-поисковики). вот что мне выдал один из них после пары запросов навскидку:
Inferno - виртуальный пост-Unix в кармане

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

RT-Linux

Туфта.

о каких НИЖНИХ СТРАНИЦАХ ты говоришь?

Пять и два.

я лично знаю всего ОДНУ машину, на которой можно подставлять страницы в адрес #8000-#bfff.

Я и не говорю об использовании этой возможности.

и если уж на то пошло, то 16 кило (а их в НИЖНИХ СТРАНИЦАХ именно столько- 16384 байта по 8 бит каждый) маловато для приложений.
а отводить всю остальную память под кучу, которая не факт что будет использована по меньшей мере нерационально.

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

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

Можно просить целыми 16К страницами и там орудовать своим распределителем.

вот именно что в НЕКОТОРЫХ, да еще когда он не используется. при этом даже не расходует процессорного времени. блеск! логика обалденная, снимаю шляпу (вместе с джинсами). а нахрена спрашивается тогда его вообще городить, если он будет эффективнее только если не будет вызываться?

Чтоб был готов придти на помощь.

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

Вот, Оберон дал весьма многочисленное потомство.
А Java-рантаймов-на-голом-железе уже столько, что лень их считать.

но скажу сразу- там ВЫДЕЛИТЕЛЬ памяти настолько же сложный насколько и эффективный. и предложенная тобой схема списков выглядит очень бледно %)

А я вроде и не предлагаю списков.

[GriV]

2Cobalt> Рекомендую тебе почитать вообще литературу по треду а также попытаться разобраться в структуре памяти и прочих ресурсов спекка, у меня создаётся ощущение что по про них (я не про сборщик мусора) ты имеешь самое общее представление.

2Moders> Необходимо закрыть тему, а то она превращается в переливание из пустого в порожнее...

[captain cobalt]

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

Имею довольно неплохое представление.

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

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

[Vitamin]

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

в этом пункте шел разговор про ОС без защиты памяти.

Туфта.

не важно. главное что существует. могу еще QNX припомнить.

Пять и два.

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

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

копируется лишь небольшой участок данных, с которым идет работа. причем с данными работа происходит не так часто как с кодом.

Можно просить целыми 16К страницами и там орудовать своим распределителем.

вот тогда ты и проси блоки ЛЮБОГО размера, от 1 до 64 секторов и там орудуй ЛЮБЫМ распределителем.

Вот, Оберон дал весьма многочисленное потомство.
А Java-рантаймов-на-голом-железе уже столько, что лень их считать.

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

А я вроде и не предлагаю списков.

а что ты предлагал? списки указателей на выделенные блоки

[captain cobalt]

в этом пункте шел разговор про ОС без защиты памяти.

Итак.
Спектрум - машина без аппаратной защиты памяти.
Большинство операционных систем для машин без защиты памяти использует сборщик мусора. Причина - если нет аппаратной защиты, нужна программная. Сборщик мусора - одна из составляющих программной защиты памяти. Вторая важная составляющая - строго типизированный язык высокого уровня. Эти средства пресекают практически все ошибки программирования и позволяют создавать надёжные программные системы. Надёжнее чем виндовс. Который работает с аппаратной защитой памяти.

Вывод - сборщик мусора нужен в ОС для Speccy.

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

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

и как ты собираешься организовывать список во внешней памяти?

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

копируется лишь небольшой участок данных, с которым идет работа. причем с данными работа происходит не так часто как с кодом.

Я до сих пор сомневаюсь. %)

вот тогда ты и проси блоки ЛЮБОГО размера, от 1 до 64 секторов и там орудуй ЛЮБЫМ распределителем.

Это будет очень неэффективно. См. выше.

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

Всё перечисленное работает на голом процессоре и самостоятельно обеспечивает свою жизнедеятельность.

а что ты предлагал? списки указателей на выделенные блоки

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

[Vitamin]

Итак.
Спектрум - машина без аппаратной защиты памяти.
Большинство операционных систем для машин без защиты памяти использует сборщик мусора. Причина - если нет аппаратной защиты, нужна программная. Сборщик мусора - одна из составляющих программной защиты памяти. Вторая важная составляющая - строго типизированный язык высокого уровня. Эти средства пресекают практически все ошибки программирования и позволяют создавать надёжные программные системы. Надёжнее чем виндовс. Который работает с аппаратной защитой памяти.

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

Вывод - сборщик мусора нужен в ОС для Speccy.

не в ОС а в каком-либо ЯВУ, который реализуется на базе ОС

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

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

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

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

Я до сих пор сомневаюсь. %)

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

Это будет очень неэффективно. См. выше.

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

Всё перечисленное работает на голом процессоре и самостоятельно обеспечивает свою жизнедеятельность.

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

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

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