VladD2 wrote:
>
> Pzz>Чтобы помечать объекты, нужен флаг. Что мешает хранить эти флаги в
> Pzz>отдельной кучке?
>
> А как ты сопоставишь эти отдельные флаги с объектами? И ты представляшь
> себе их количество? Их же должно быть столько сколько объектов.
>
> К тому же граф строится путем объхода самих объектов. Их полей.
>
> В общем, лечше разберись в вопросе, а то твои предложения звучат совсем
> смешно.

Это от недостатка воображения

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

Здравствуйте, VladD2, Вы писали:

VD>ЖЦ и виртуальная память плохо дружат. Дело в том, что сборка мусора поднимит все данные в память, и если физической памяти не хватает, то начнется кольцивой свопинг, так что для ОС основанной на ЖЦ вопрос с виртуальной памяти можно не рассматривать.

Вопрос в том, когда начинается сеанс GC. Даже в такой ОС GC должен работать в пределах приложения. Далее. У разработчиков ОС есть все возможности по контролю страниц виртуальной памяти. Т.е. работу GC можно связать с менеджером виртуальной памяти. Например, перед отправлением страницы на диск, выполнять GC в этом процессе, запоминать/отмечать сей факт и т.д. Т.е. можно продумать, как избежать подъема виртуальных страниц в процессе GC.

Я уверен, что GC исполняется не медленнее, чем запись страниц виртуальной памяти на диск. К тому же, нам опять же не надо переключать контексты в нашем едином адресном пространстве. Поэтому, подобные способы вряд ли сильно замедлят общую картинку. Опять же, после сеанса GC. Опять же, после сеанса GC нам в общем случае придется скидывать на диск меньше страниц, что еще более улучшит время свопа.

VD>Когда же подобная ОС дойдет до промышленной эксплуатации, то говорить о чем-то отличном от 64-битных камней будет не серьезно. Ну, или на них можно смело бабить.

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


VD>Драйверы не могут содержать небезопасный код. Но это не значит, что процесс драйверов не может содержать доверительного небезопасного кода. В описании Синкулярити сказано, что в код драйверов подмешивается доверительный код (на базе CTR — рефлексии времени компиляции). Точно так же код прикладных процессов может содержать доверительный код генерируемый компилятором или рантайомом. Так что безопасность драйверов не означает невозможность использования трюков повышающих производительность.

Вопрос стоит более прямо. Смогу я залезть из драйвера в произвольную область памяти или нет? Ответ для меня важен, сам понимаешь почему.

VD>Меня вообще занимает не технический, а марально-экономический аспект. Ведь у МС есть 100 тысяч драйверов написаных на С/С++ которые для новой ОС прийдется переписать с нуля. Пусть даже на 2 трети они забьют, но ведь и без этого объем работы колосальный! А ведь еще прийдется переписать GUI, 3D, средства комуникции, серверы приложений... Один MS SQL — это уже огромнейшая работа.

V>> И в чем отличие unsafe от unmanaged? Только лишь в отличие байт-кода от нативного? Это непринципиально при прямом доступе к памяти или другим частям железки.

VD>Отличие в том, что при манипуляции с управляемымии данными ты защищен от ошиблок.

Угу, пока не сделали fixed. И прощай все.


VD>Думаю Сингулярити ни на что не рассчитана. Это исследование. И что оно покажет еще чер не знает. Вот они уже хвастаются очень малым расходом памяти на процессы.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Я думаю, что реально спроектировать систему управления памятью, которая
Pzz>не будет поднимать все объекты из свопа с целью сборки мусора. Но я не
Pzz>буду заниматься доказательством этого утверждения...

Даже этого ничего не надо. Сам GC и подсистема управления виртуальной памятью могут быть объединены в единый механизм. Т.е. у GC должна быть вся информация о наличии или отсутствии страниц в памяти.

Здравствуйте, Cyberax, Вы писали:

C>Pzz совершенно прав — нормальный GC не должен свопить во время малых
C>сборок, так как все нужные страницы и так уже есть в памяти. Вот во
C>время большой сборки — действительно нужно все загружать.

ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все остальные (в том числе реалтаймнве инкриментальные).

Так вот первые будут приводить к свопингу при сборке второго поколения. Вторые — всегда. Учитывая же, что при реализации ЖЦ все авторы стремятся собрать память во втором поколениии если не хватает свободной физической памяти, то автоматически будет начинаться вопинг.

Короче вы живете в каком-то страном мире сових фантазий. Между тем ЖЦ-алгоритмы принципиально не рассчитаны на жизнь в условиях когда физической памяти меньше чем виртуальной занятой. И тут ничего не поделаешь. Попробуйте создать эксперемент с Явой или дотнетом. Создайте много объектов в начале работы приложения и поместите их в массив. Их объем должен быть на уровне объема физической памяти доступной в системе. Далее начните в цикле создавать и удалять объекты. Увидите, что ваше приложение сурово сядет на своп. А елси при этом посмотреть на поведение ЖЦ, то можно будет заметить Н-ное количество сборок мусора второго покления. Ворксет процесса при этом будет постоянно подниматься и опускаться.

C>Все просто — не надо обходить ВСЕ объекты, а только те, которые
C>изменились с предидущей сборки. Это достигается с помощью card marking'а
C>или трюков с защитой памяти.

Это можно сделать только при эфимерной сборке. Собственно так и делается. При сборке последнего поколения ты обязан обойти все объекты. А в условиях нехватки памяти первым делом пытаются произвести полную сборку (т.е. собрать старейшее поколение). К тому же считается, что сборщики основанные на поколениях не обеспечивают реалтаймных характеристик. А инкрементальные бсорщики всегда читают весь грах приложения.

В общем, ЖЦ и виртуалка хреново совмещаются. Так что не велика потеря. Ну, или прийдется изобретать новые приципы работы с вируалкой. Я лично пока что их не вижу.

vdimas wrote:
>
> Pzz>Я думаю, что реально спроектировать систему управления памятью, которая
> Pzz>не будет поднимать все объекты из свопа с целью сборки мусора. Но я не
> Pzz>буду заниматься доказательством этого утверждения...
>
> Даже этого ничего не надо. Сам GC и подсистема управления виртуальной
> памятью могут быть объединены в единый механизм. Т.е. у GC должна быть
> вся информация о наличии или отсутствии страниц в памяти.

В нормальной ОС на обычном железе это трудно сделать, т.к. paging в
ядре, а GC в user space. Кроме того, GC очень уж language и
application-specific, а paging это гораздо более общая вещь.

Впрочем, "трудно" не означает "невозможно".

Здравствуйте, vdimas, Вы писали:

V>Даже этого ничего не надо. Сам GC и подсистема управления виртуальной памятью могут быть объединены в единый механизм. Т.е. у GC должна быть вся информация о наличии или отсутствии страниц в памяти.

Предположим, что это есть (такие реализации даже есть в природе). И как при этом ты видишь рабту ЖЦ?

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

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

Первая же полная сборка и весь своп будет в памяти.

Здравствуйте, vdimas, Вы писали:

V>Вопрос в том, когда начинается сеанс GC. Даже в такой ОС GC должен работать в пределах приложения.

И что?

V> Далее. У разработчиков ОС есть все возможности по контролю страниц виртуальной памяти. Т.е. работу GC можно связать с менеджером виртуальной памяти.

Это можно сделать и сейчас. Особенно МС.

V> Например, перед отправлением страницы на диск, выполнять GC в этом процессе, запоминать/отмечать сей факт и т.д. Т.е. можно продумать, как избежать подъема виртуальных страниц в процессе GC.

Ты вообще понимашь что говоришь? Представь себе. ОС хочет скинуть 10 страниц на винт и ради этого она будет проводить ЖЦ вего процесса.

К тому же ЖЦ такой механизм, что тонна мусора может появиться в результате правки одного указателя. Так что правка одной страницы может привести к тому, что большая часть отсвапованных страниц будет мусором. Но чтобы это выяснить прйдется загрузить все в память и произвести сборку мусора.

V>Я уверен, что GC исполняется не медленнее, чем запись страниц виртуальной памяти на диск.

Это зависит. Например полный ЖЦ может длиться секунды (особенно инкриментальный) на большом процессе. Но не об этом речь. Ты мехонизм опиши. Как ВМ и ЖЦ будут жить и не драться между собой? В Виндовс они дерутся по страшному.

V> К тому же, нам опять же не надо переключать контексты в нашем едином адресном пространстве.

И? Одна операция с винтом стоит тысячи переключений контекста.

V> Поэтому, подобные способы вряд ли сильно замедлят общую картинку. Опять же, после сеанса GC. Опять же, после сеанса GC нам в общем случае придется скидывать на диск меньше страниц, что еще более улучшит время свопа.

А есть ли смысл вообще что-то куда-то скидывать? Ведь копирующий ЖЦ обеспечивает дефрагментацию памяти. Так что в ней будет только то что нужно.

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

V>Может быть. Хотя, я уверен, что в первую очередь эта ОС получит распространение на всяких встраиваемых устройствах, или там WEB-терминалах, или банкоматах и т.д. И надо признать, что в этих задач требования к памяти далеко не астрономические.

Думаю, что удачная ОС нашла бы себе применение везде. Вот только надо чтобы ее проталкивали монстры вроде МС. А то даже самая удачная идея загнется.

V>Вопрос стоит более прямо. Смогу я залезть из драйвера в произвольную область памяти или нет? Ответ для меня важен, сам понимаешь почему.

Ты, как программист — нет. Но ОС может помочь тебе оптимизировав те или иные операции.
Вот для обмена сообщениями Сингулярити явно занимается хаками. Там физически передаются только адреса, а сами сообщения лежат в разделяемой куче.

VladD2 wrote:
> ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все
> остальные (в том числе реалтаймнве инкриментальные).
FYI, инкрементальные GC вполне себе работают с поколениями. Насчет
realtime особо не интересовался.

> Так вот первые будут приводить к свопингу при сборке второго поколения.
Я вроде бы говорил про сборку вообще. Понятно, что при полном цикле
сборки придется загрузить все объекты. Хотя и тут возможны варианты
(кластеры объектов, например).

> Это можно сделать только при эфимерной сборке.
Кстати, пишется "эфемерной". А то уже несколько человек начали
неправильно писать это слово вслед за тобой

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все
>> остальные (в том числе реалтаймнве инкриментальные).
C>FYI, инкрементальные GC вполне себе работают с поколениями.

Икриментальные ЖЦ не могут рабоать с поколениями. Это разные алгоритмы. Можно их испльзовать совместно. Например, использовать инкрементальный ЖЦ для полной сборки и обычный, копирующий для эфимерных поколений. Но это уже будет гибрид наследующий все свойства обоих методов. А у обоих кроме хороший сторон есть еще и плохие.

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

C>Насчет realtime особо не интересовался.

Еще не все потеряно.

>> Так вот первые будут приводить к свопингу при сборке второго поколения.
C>Я вроде бы говорил про сборку вообще. Понятно, что при полном цикле
C>сборки придется загрузить все объекты.

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

C>Хотя и тут возможны варианты
C>(кластеры объектов, например).

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

>> Это можно сделать только при эфимерной сборке.
C>Кстати, пишется "эфемерной". А то уже несколько человек начали
C>неправильно писать это слово вслед за тобой

Да, я все время путаю его написание. Ну, да это не единственное изковерканное мной слово .

C>--
C>С уважением,
C> Alex Besogonov (alexy@izh.com)

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

VladD2 wrote:
>> > ЖЦ можно разделить на два вида. 1. Основанных на поколениях. 2. Все
>> > остальные (в том числе реалтаймнве инкриментальные).
> C>FYI, инкрементальные GC вполне себе работают с поколениями.
> Икриментальные ЖЦ не могут рабоать с поколениями. Это разные алгоритмы.
> Можно их испльзовать совместно. Например, использовать инкрементальный
> ЖЦ для полной сборки и обычный, копирующий для эфимерных поколений. Но
> это уже будет гибрид наследующий все свойства обоих методов. А у обоих
> кроме хороший сторон есть еще и плохие.
Я это знаю. Просто ваше деление на два типа: generational и incremental
неверное.

> Дык, а когда и зачем по-твоему производится полная сборка мусора? Один
> из случаев — нехватка памяти. Так что на лицо пардокс. При нехватке
> памяти нужно запускать полную сборку, а она еще больше усугубит положение.
Значит надо думать как это исправить.

> C>Хотя и тут возможны варианты
> C>(кластеры объектов, например).
> Какие кластеры? Ты можешь двигать объекты совмесно, но вычисление графа
> при полной сборке неминуемо поднимит все объекты в память.
Очень часто объекты хранятся в виде массивов (в коллекциях, например), и
одной из консервативных стратегий оптимизации является политика "если
есть ссылка на объект коллекции, то значит вся коллекция живая". Это
позволяет не проверять все объекты массива — получается неплохой прирост
в производительности. Есть еще несколько хитрых алгоритмов — на ACMе
было, но у меня сейчас нет туда доступа.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Я это знаю. Просто ваше деление на два типа: generational и incremental
C>неверное.

Не на generational и incremental, а на generational и остальные. Гибриды все равно являются generational.

>> Дык, а когда и зачем по-твоему производится полная сборка мусора? Один
>> из случаев — нехватка памяти. Так что на лицо пардокс. При нехватке
>> памяти нужно запускать полную сборку, а она еще больше усугубит положение.
C>Значит надо думать как это исправить.

Уже многие думали. Ну, да если будет решение, пиши. Может двинишь науку вперед.

C>Очень часто объекты хранятся в виде массивов (в коллекциях, например), и
C> одной из консервативных стратегий оптимизации является политика "если
C>есть ссылка на объект коллекции, то значит вся коллекция живая". Это
C>позволяет не проверять все объекты массива — получается неплохой прирост
C>в производительности. Есть еще несколько хитрых алгоритмов — на ACMе
C>было, но у меня сейчас нет туда доступа.

Масси может хранить ссылочные или влэью-типы. Причем вэлью-типы могут содержать или не содержать ссылочные поля. Только в случае если массив хранит вэлью-типы не содержащие ссылочные поля можно можно не сканировать все тело массива. Более того так оно и происходит на практике. В других же случаях прийдется проводить сканирование, так как нельзя предсказать на что ссылаются ячейки массива (или поля внедренных в него вэлью-типов).

Надеюсь не нужно обяснить что означает сканирование?

VladD2 wrote:
> C>Я это знаю. Просто ваше деление на два типа: generational и incremental
> C>неверное.
> Не на generational и incremental, а на generational и остальные. Гибриды
> все равно являются generational.
Тогда извиняюсь, неправильно понял.

> C>Значит надо думать как это исправить.
> Уже многие думали. Ну, да если будет решение, пиши. Может двинишь науку
> вперед.
Год назад об этом думал очень плотно — была пара новых идей как слегка
ускорить GC. Сейчас мне больше интересны алгоритмы детерминированого
управления памятью и их взаимодействие с GC.

Кстати, нашел интересную статью:
http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
refcounter'а увеличить отзывчивость GC на два порядка.

> Масси может хранить ссылочные или влэью-типы.Причем вэлью-типы могут
> содержать или не содержать ссылочные поля.
Смысл как раз в том, что это все упаковывается во время первой полной
сборки в "кластер", который идет сплошным блоком в памяти (и не
ссылается на другие объекты). Достаточно часто это бывает возможно, что
дает некоторый прирост в скорости.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Кстати, нашел интересную статью:
C>http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
C>refcounter'а увеличить отзывчивость GC на два порядка.

У меня на эту ссылку открывается какя-то фигня. Но судя по слову "refcounter" речь идет о подсчете ссылок.
У этого подхода куча своих проблем. И даже спаривание его с рассчетом графа достижимости не дает хорошего резельтата.

C>Смысл как раз в том, что это все упаковывается во время первой полной
C>сборки в "кластер", который идет сплошным блоком в памяти (и не
C>ссылается на другие объекты). Достаточно часто это бывает возможно, что
C>дает некоторый прирост в скорости.

Что там возможно? Пойми, нельзя изменять формат объекта на ходу. А ссылка в лбой момент может измениться и начать указывать бог знает куда. Так что при полной сборке мусора никуда от полного сканирования графа объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.

C>--
C>С уважением,
C> Alex Besogonov (alexy@izh.com)

Еща раз прошу пернести подпись в профайл.

VladD2 wrote:
> C>Кстати, нашел интересную статью:
> C>http://citeseer.ist.psu.edu/levanoni01fly.html — как с помощью простого
> C>refcounter'а увеличить отзывчивость GC на два порядка.
> У меня на эту ссылку открывается какя-то фигня. Но судя по слову
> "refcounter" речь идет о подсчете ссылок.
Там в правом верхнем углу ссылка на PDF.

Вот прямая ссылка, но на PS:
http://www.cs.technion.ac.il/%7Eerez/Papers/refcount.ps
Взято отсюда: http://www.cs.technion.ac.il/~erez/publications.html

> У этого подхода куча своих проблем. И даже спаривание его с рассчетом
> графа достижимости не дает хорошего резельтата.
Как раз наоборот — за счет refcount'а сразу убивается куча объектов
нулевого поколения.

> C>Смысл как раз в том, что это все упаковывается во время первой полной
> C>сборки в "кластер", который идет сплошным блоком в памяти (и не
> C>ссылается на другие объекты). Достаточно часто это бывает возможно, что
> C>дает некоторый прирост в скорости.
> Что там возможно? Пойми, нельзя изменять формат объекта на ходу. А
> ссылка в лбой момент может измениться и начать указывать бог знает куда.
Ты не понял, во время цикла полной сборки граф объектов разделяется на
набор кластеров. При этом кластеры характеризуются тем, что не имеют
ссылок на внешние относительно кластера объекты. Затем эти кластеры
упаковываются в памяти таким образом, что их объекты расположены всплошную.

Соответственно, достаточно часто можно делать предположение, что если
есть ссылка на любой объект кластера, то весь кластер можно оставить
жить. При этом кластер не имеет ссылок на внешние объекты, так что его
не надо сканировать.

> Так что при полной сборке мусора никуда от полного сканирования графа
> объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.
Полный обход можно оптимизировать, если принять некоторые консервативные
предположения.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>Там в правом верхнем углу ссылка на PDF.

Ага. Понял. Я часто попадал на такие же страницы, но никак не мог понять, что с ними делать.

Ладно. Спасибо, погляжу. Хотя уже заголовок уже все говорит за себя.

>> У этого подхода куча своих проблем. И даже спаривание его с рассчетом
>> графа достижимости не дает хорошего резельтата.
C>Как раз наоборот — за счет refcount'а сразу убивается куча объектов
C>нулевого поколения.

Проблема в том, что подсчет ссылок, особенно в многозадачной среде — это довольно дорогое удовольствие. Есть не одна научная работа доказывающая, что инкрементальный коллектор дает лучшие результаты.

Основаня проблема в том, что каждый инкремент/декремент должен сопровождаться блокировкой. А это довольно дорогое удовольствие. Блокировка может в 4-5 раз сократить эффективность. А ведь инкремент/декремент происходит при кадом копировании ссылок.

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

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

А как это ты обеспечишь, что в этих кластерах не будет перекресных ссылок? Это на каждое пересечение кластеров нужно строить набор корней класстеров. А это ой как не дешево.

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

Ерунда. Ссылка может быть на один листовой объект. Тут без анализа ничерта не сделашь.

C> При этом кластер не имеет ссылок на внешние объекты, так что его
C>не надо сканировать.

Так тоже быть не может. Ссылки будут обязательно. Без хранения корней класстера это работать не будет.

>> Так что при полной сборке мусора никуда от полного сканирования графа
>> объектов не уйти. Это инвариант алгоритма. От этого никуда не уйти.
C>Полный обход можно оптимизировать, если принять некоторые консервативные
C>предположения.

Какие?

Здравствуйте, Ligen, Вы писали:

L>(хотя фраза "зачем мне это знать?" звучит всегда дико и убийственно, ИМХО).

Во многом знании много печали, и преумножающий знания преумножает скорбь. (С) Экклезиаст

VladD2 wrote:
> C>Там в правом верхнем углу ссылка на PDF.
>
> Ага. Понял. Я часто попадал на такие же страницы, но никак не мог
> понять, что с ними делать.
>
> Ладно. Спасибо, погляжу. Хотя уже заголовок уже все говорит за себя.
>
>> > У этого подхода куча своих проблем. И даже спаривание его с рассчетом
>> > графа достижимости не дает хорошего резельтата.
> C>Как раз наоборот — за счет refcount'а сразу убивается куча объектов
> C>нулевого поколения.
>
> Проблема в том, что подсчет ссылок, особенно в многозадачной среде — это
> довольно дорогое удовольствие. Есть не одна научная работа доказывающая,
> что инкрементальный коллектор дает лучшие результаты.
>

> Основаня проблема в том, что каждый инкремент/декремент должен
> сопровождаться блокировкой. А это довольно дорогое удовольствие.
Которого вполне можно избежать в большинстве случаев Предположим, что
при первом использовании переменной в текущем потоке мы увеличиваем ее
счетчик на 1 и создаем thread-local счетчик. Теперь мы можем его
нормально инкрементировать и декрементировать — блокировка нужна будет
только когда локальный счетчик дойдет до 0.

> Вторая проблема — циклы. Для их разруливания один фиг приходится строить
> граф достицимости. А тогда инкрементальная схема уже мало чем отличается.
Тут будет плюс в том, что в реальных приложениях циклы обычно не
составляют большей части объектов. Питон, например, как раз и использует
refcounter и детектор циклов.

> А как это ты обеспечишь, что в этих кластерах не будет перекресных
> ссылок? Это на каждое пересечение кластеров нужно строить набор корней
> класстеров. А это ой как не дешево.
В кластеры загоняются не все объекты, это я немного неясно выразился. То
есть часть объектов так и остается в виде обычном некластеризованом виде.

> C>Соответственно, достаточно часто можно делать предположение, что если
> C>есть ссылка на любой объект кластера, то весь кластер можно оставить
> C>жить.
> Ерунда. Ссылка может быть на один листовой объект. Тут без анализа
> ничерта не сделашь.
Я же говорю — консервативное предположение, которое обычно вполне
оправдывается. Можно использовать эвристику — после создания кластера во
время первой полной сборки проверить будет ли кластер жив целиком.

> C> При этом кластер не имеет ссылок на внешние объекты, так что его
> C>не надо сканировать.
> Так тоже быть не может. Ссылки будут обязательно. Без хранения корней
> класстера это работать не будет.
Корни ссылаются _на_ кластер, из самого кластера ссылок вовне нет.

> C>Полный обход можно оптимизировать, если принять некоторые консервативные
> C>предположения.
> Какие?
Кластерная стратегия, partial-scan и т.п.

Здравствуйте, Cyberax, Вы писали:
>> Основаня проблема в том, что каждый инкремент/декремент должен
>> сопровождаться блокировкой. А это довольно дорогое удовольствие.
C>Которого вполне можно избежать в большинстве случаев Предположим, что
C>при первом использовании переменной в текущем потоке мы увеличиваем ее
C>счетчик на 1 и создаем thread-local счетчик. Теперь мы можем его
C>нормально инкрементировать и декрементировать — блокировка нужна будет
C>только когда локальный счетчик дойдет до 0.
Что-то мне непонятно.
1. Как выполняется передача указателя в другой поток?
2. Я правильно понимаю, что при достижении локального нуля мы блокируемся и начинаем сканировать весь список рефкаунтов на предмет ненулевых значений?
В общем, поясни плиз подробнее.

Здравствуйте, eao197, Вы писали:

E>Геннадий, ты пропустил нашу драку с Владом по этому поводу Re[18]: Следующий язык программирования

Автор: eao197
Дата: 08.10.05

Нет, это ты упустил "драки" ГВ vs AndrewVK+Vlad2+IT, проходившие года эдак три назад. Удивительно, но оказывается, люди ещё не досказали что-то друг друг...

Здравствуйте, DarkGray, Вы писали:

VD>>А свои что бесплатные? Или все кто пишут на С++ сразу автоматом получают манию величия в форме веры в свою непогрешимость?

DG>Свое бревно — глаз не колет.

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