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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

31.03.2005, 14:38
captain cobalt

Цитата:

Сообщение от elf/2

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

Нету. :)

Цитата:

Сообщение от elf/2

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

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

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

Цитата:

Сообщение от elf/2

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

Поэтому здесь ответ зависит от низкоуровневого представления указателя, по поводу чего нет консенсуса среди меня.
31.03.2005, 14:56
elf/2

Цитата:

Сообщение от captain cobalt

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

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

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

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

Цитата:

Сообщение от captain cobalt

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

загляни-ка в интернет (существуют такие специальные сайты-поисковики). вот что мне выдал один из них после пары запросов навскидку:
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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от spectrum

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

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

Цитата:

Сообщение от spectrum

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

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

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

Цитата:

Сообщение от spectrum

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

RT-Linux

Туфта.

Цитата:

Сообщение от Vitamin

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

Пять и два.

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

А я вроде и не предлагаю списков.
31.03.2005, 19:11
GriV

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

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

Цитата:

Сообщение от GriV

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

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

Цитата:

Сообщение от GriV

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

Туфта.

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

Цитата:

Сообщение от captain cobalt

Пять и два.

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

а что ты предлагал? списки указателей на выделенные блоки
31.03.2005, 22:06
captain cobalt

Цитата:

Сообщение от Vitamin

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

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от Vitamin

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Цитата:

Сообщение от captain cobalt

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

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

Показывать 40 сообщений этой темы на одной странице