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

[elf/2]

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

давайте вернемся к истокам...

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

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

[Advertiser]

[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 бит каждый) маловато для приложений.
а отводить всю остальную память под кучу, которая не факт что будет использована по меньшей мере нерационально.

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

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

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

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

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

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

[captain cobalt]

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

Нету.

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

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

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

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

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

[elf/2]

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

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

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

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

[captain cobalt]

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

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

RT-Linux

Туфта.

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

Пять и два.

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

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

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

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

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

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

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

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

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

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

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

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

[GriV]

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

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

[Vitamin]

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

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

Туфта.

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

Пять и два.

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

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

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

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

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

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

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

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

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

[Alex/AT]

Тут проскакивала идея про свопинг кода. Так вот. Идея не катит Ибо даже если код будет специально написан, никто в большой программе типа компилятора не исключает частых вызовов в другие страницы свопа и возвратов из них. А это, сами понимаете, геморрой. Если дублировать все эти вызовы, программа распухнет "донельзя". Свопить данные проще - ибо под такой своп программу легче оптимизировать.

[Vitamin]

Тут проскакивала идея про свопинг кода. Так вот. Идея не катит Ибо даже если код будет специально написан, никто в большой программе типа компилятора не исключает частых вызовов в другие страницы свопа и возвратов из них. А это, сами понимаете, геморрой. Если дублировать все эти вызовы, программа распухнет "донельзя". Свопить данные проще - ибо под такой своп программу легче оптимизировать.

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

[captain cobalt]

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

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

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

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