Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Механизм управления памятью (нужна оценка идеи)

40K
15 июля 2008 года
xDragon
6 / / 15.07.2008
в процессе разработки одной системы, встал вопрос об автоматическом управлении памятью. работаю с объектной моделью. в общем случае используются структуры типа графа (тоесть нельзя использовать деревья)

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

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

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

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

Насколько данная идея адекватна?
412
15 июля 2008 года
grgdvo
323 / / 04.07.2007
Из описанного не понял чем идея лучше (или хуже) классического варианта подсчета ссылок на объект. По моему на лицо те же грабли: взаимное использование объектов, круговое использование объектов, массивы объектов и т.п.
11
15 июля 2008 года
oxotnik333
2.9K / / 03.08.2007
Очень похоже на механизм распределения/очистки памяти в CLR
Подробней читай "Язык программирования C# 2005и платформа .NET 2.0" Эндрю Троелсен (стр. 250-269)
5
15 июля 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: xDragon
в процессе разработки одной системы, встал вопрос об автоматическом управлении памятью. работаю с объектной моделью. в общем случае используются структуры типа графа (тоесть нельзя использовать деревья)

Обычная задача автоматического сборщика мусора. Великолепно решается в Java или .NET.
В этимх средах поддерживается концепция "слабых ссылок" (WeakReference), когда Мы имеем связь с объектом опосредовано, через спец. структуру данных, позволяющую сборщику мусора освободить память под объектом, когда на него пропадают все "жесткие" ссылки - прямые указатели.

5
15 июля 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: grgdvo
Из описанного не понял чем идея лучше (или хуже) классического варианта подсчета ссылок на объект.

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

40K
15 июля 2008 года
xDragon
6 / / 15.07.2008
grgdvo, идея лучше тем, что мы в любой момент можем узнать, кто конкретно удерживает объект в памяти, таким образом можем контролировать и циклические зависимости и более сложные случаи.

oxotnik333, спасибо за информацию! Приятно, когда указывают с точностью до страници. Я прочитал. Там идея очень общая, непонятно как конкретно они строят этот самый объектный граф. У меня же предполагается, что такой граф уже построен, и программа работает непосредственно с ним.

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

В общем случае я понял, что идея адекватна :) Спасибо ответившим :) Ещё по поводу дотнета хочу сказать следующее - я пишу механизм управления памятью, а не сборщика мусора, т.е. спецификой является то, что объект удаляется из памяти именно тогда, когда не нужен (т.е. понятие мусора, как таковое отсутствует).
1
15 июля 2008 года
kot_
7.3K / / 20.01.2000
Ну так это и есть концепция "уборщика мусора" - этоже не гворит что то что он убирает - это мусор - это ссылки которые перестали быть адекватными :)
5
16 июля 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: xDragon
Если ты знаешь, то вопрос: есть ли в дотнете такие связи (которые не обязывают объект оставаться в памяти, и сами выставляются в null при разрушении объекта)?

Класс System.WeakReference. У него есть свойство IsAlive, сообщающее о существовании объекта в текущий момент времени.

Цитата:
я пишу механизм управления памятью

Зачем?

11
16 июля 2008 года
oxotnik333
2.9K / / 03.08.2007
Цитата: xDragon
Там идея очень общая, непонятно как конкретно они строят этот самый объектный граф. У меня же предполагается, что такой граф уже построен, и программа работает непосредственно с ним.


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

40K
17 июля 2008 года
xDragon
6 / / 15.07.2008
Сложно объяснить, зачем... Просто провожу эксперимент, ищу альтернативные пути взамен уже существующих.

oxotnik333, ну не совсем поиск, а отслеживание момента, когда таких связей у объектов не остаётся (иначе больше никак объект найти будет нельзя). Насчёт выделения не понял. Объекты выделяются стандартнфми средствами (new), а позже могут быть связаны с другими.
5
17 июля 2008 года
hardcase
4.5K / / 09.08.2005
Цитата: xDragon
ну не совсем поиск, а отслеживание момента, когда таких связей у объектов не остаётся (иначе больше никак объект найти будет нельзя). Насчёт выделения не понял. Объекты выделяются стандартнфми средствами (new), а позже могут быть связаны с другими.

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

40K
17 июля 2008 года
xDragon
6 / / 15.07.2008
Есть механизм уведомлений о разрушении связей, таким образом можно избавиться от "классических алгортмов сборщика мусора", а реализовать очищение непосредственно в момент удаления нужных связей. Связи считаются не численно, а массивом указателей.

:)
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог