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

[captain cobalt]

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

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

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

ОК.
Предположим, что размер указателя будет 16 бит. Используется модель, в которой указатель - это хэндл блока памяти на куче. Таким образом, максимум 64K блоков на куче на всю систему.

Будет системный вызов РАЗЫМЕНОВАТЬ УКАЗАТЕЛЬ, в который передаётся указатель, результат - устанавливается нужная страница и возвращается адрес блока внутри неё. Теперь блок можно адресовать напрямую. Кроме того, имеет смысл сделать вызов КОПИРОВАНИЕ из блока, указываемого одним указателем, в блок указываемый другим указателем того же типа. Это копирование может происходить из одной страницы в другую. Это нужно, чтобы сделать операции копирования явными.

-как ты собираешься бороться со страничностью памяти

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

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

Всё равно бесполезное занятие. Лучше даже и не пробовать. Неплохое решение - использование сильно типизированного языка высокого уровня.

-как обеспечить общую память с возможностью copy-on-write

Общую память - очень просто: одна программа даёт второй программе указатель, который тут же можно использовать по назначению. Если неизвестно, какая программа завершится раньше, а какая позже - тут и развернётся сборщик мусора во всей красе.
COW для блоков памяти на куче? Забавно.
Но также вполне возможно. Конечно же понадобятся вызовы вроде "разыменовать для записи", "разыменовать для чтения", "разыменовать для чтения\записи" и т. п.

[Alex/AT]

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

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

А насчет псевдоуказателей - это излишество. Ибо всегда "возвращать" адрес в регистре неудобно - иногда нужны фиксированные обращения, для оптимальной производительности. Да и какая нафиг сборка мусора в машине с 64к адресного пространства и метром памяти. Любой memleak 99% сгубит приложение нафиг и сразу.

[captain cobalt]

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

Вот и я говорю. Если только одна задача, использующая кучу на 1К, действительно, проблем никаких.

[Vitamin]

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

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

ОК.
Предположим, что размер указателя будет 16 бит. Используется модель, в которой указатель - это хэндл блока памяти на куче. Таким образом, максимум 64K блоков на куче на всю систему.

сколько весит хэндл? каким образом они хранятся? где?

Будет системный вызов РАЗЫМЕНОВАТЬ УКАЗАТЕЛЬ, в который передаётся указатель, результат - устанавливается нужная страница и возвращается адрес блока внутри неё. Теперь блок можно адресовать напрямую. Кроме того, имеет смысл сделать вызов КОПИРОВАНИЕ из блока, указываемого одним указателем, в блок указываемый другим указателем того же типа. Это копирование может происходить из одной страницы в другую. Это нужно, чтобы сделать операции копирования явными.

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

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

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

Всё равно бесполезное занятие. Лучше даже и не пробовать. Неплохое решение - использование сильно типизированного языка высокого уровня.

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

Общую память - очень просто: одна программа даёт второй программе указатель, который тут же можно использовать по назначению. Если неизвестно, какая программа завершится раньше, а какая позже - тут и развернётся сборщик мусора во всей красе.
COW для блоков памяти на куче? Забавно.

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

Но также вполне возможно. Конечно же понадобятся вызовы вроде "разыменовать для записи", "разыменовать для чтения", "разыменовать для чтения\записи" и т. п.

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

далее вопрос. как реализовать подкачку? и многозадачность- вот краеугольный камень в твой огород %)

[Vitamin]

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

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

А насчет псевдоуказателей - это излишество. Ибо всегда "возвращать" адрес в регистре неудобно - иногда нужны фиксированные обращения, для оптимальной производительности. Да и какая нафиг сборка мусора в машине с 64к адресного пространства и метром памяти. Любой memleak 99% сгубит приложение нафиг и сразу.

ну это все решается на практике. потому как отличий между теорией и практикой на практике больше, чем в теории (с) ктото умный %)

[captain cobalt]

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

Достаточно велик. Значительная их часть является в большой степени time-critical. И поэтому нельзя позволить себе интенсивно копировать их данные.

поэтому упор надо делать на именно локальную память.

Хорошая реализация локальности - установить страницу и работать с ней. Но с возможностью так же быстро установить любую другую страницу.

мы предлагали то же самое.

Ну вот.

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

Остальное - мелочи.

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

Я планирую сначала посмотреть, сколько там теряется на внутренней фрагментации. Вдруг дополнительные телодвижения не ст0ят свеч.

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

Первичная информация - куча состоит из блоков. Занятых и свободных. Каждый блок принадлежит странице.

ну это все решается на практике. потому как отличий между теорией и практикой на практике больше, чем в теории (с) ктото умный %)

В теории, между практикой и теорией разницы быть не должно.

Пойду-ка раскочегаривать z80 ассемблер, и пытаться набивать инструкции.

[Vitamin]

Достаточно велик. Значительная их часть является в большой степени time-critical. И поэтому нельзя позволить себе интенсивно копировать их данные.

не скажи. назову два типа приложений, которым нужнен большой объем памяти- текстовые редакторы и потоковые обработчики (видео, звук и т.д.).
первый случай не является критичным по времени. проблема в модифицировании ВСЕХ данный при сравнительно небольших изменениях (вставка нескольких байт например). решается с помощью системных функций, которые будут из нижней памяти напрямую рулить верхними страницами самым быстрым способом (например, используя дма, если он есть).
во втором случае получаем около 20-25 лишних тактов на каждый байт (копирование в окно). но! зато имеется прекрасная возможность реализовать файлы, проецируемые в память (типа в окно копируем не участок верхней памяти, а читаем напрямую с диска, процессу не суть важно).

Хорошая реализация локальности - установить страницу и работать с ней. Но с возможностью так же быстро установить любую другую страницу.

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

Ну вот.
А все отличия уже упомянуты. Конспективно вкратце:
-- хочу чтобы код был внизу а данные вверху
-- не хочу вытесняющую многозадачность
-- хочу сборщик мусора; для этого дополнительно понадобится хранение информации о типах блоков (где внутри них есть указатели)
Остальное - мелочи.

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

Я планирую сначала посмотреть, сколько там теряется на внутренней фрагментации. Вдруг дополнительные телодвижения не ст0ят свеч.
Первичная информация - куча состоит из блоков. Занятых и свободных. Каждый блок принадлежит странице.

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

В теории, между практикой и теорией разницы быть не должно.

Пойду-ка раскочегаривать z80 ассемблер, и пытаться набивать инструкции.

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

[SfS]

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

[captain cobalt]

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

ИМХО, ещё б0льшее витание в облаках.

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

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

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

Это и есть крутая фича.

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

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

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

Да, попробую.

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

Хотелось почитать, но там doc оказался. И лень было идти к машине с вордом. Но схожу.

[SfS]

Хотелось почитать, но там doc оказался. И лень было идти к машине с вордом. Но схожу.

В каком формате удобнее ? Если не DOC - то любой другой, где поддержаны таблицы (я сам документ делал в ОпенОффисе под Линуксом)