K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?
А он хорош Все четко расписал, плюс немного и водой разбавил, чтобы текста для Шымжа побольше было.

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

K>Раньше спрашивали: ты гуглил прежде чем задать вопрос. Теперь гугл умер, и я спрашиваю ты поговорил с ChatGPT прежде чем задать вопрос на форуме?

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

По сути не ответила:

	Скрытый текст

Причины по сути нет — можно добавить такой gc_ptr.

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

S>Ок, а почему бы не добавить шибко вумный универсальный, чтобы с его использованием все работало как в современных ЯП типа Java/C#/Swift/Dart? Ну т.е. ту самую сборку мусора.

Когда-то давно я писал для С++ гибридный сборщик мусора. По своей сути он был основан на подсчете ссылок, но умел при этом разрывать циклические ссылки, решая таким образом основную проблему простого подсчета ссылок. Это умение возвышало его из ранга самодельного smart pointer'a до ранга полноценного сборщика мусора.

Этот мини-GC не включался для всего проекта глобально. Вместо этого, программист должен был использовать специальные GCPtr<T> указатели в тех местах, где он хотел видеть сборку мусора.

Исходник этого GC был очень маленьким и работал предельно шустро, решая возложенные на него задачи. Писался он чтобы решить дилемму сложных многоуровневых циклических ссылок, которая то тут, то там возникала в проектах над которыми я работал.

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

A>По своей сути он был основан на подсчете ссылок, но умел при этом разрывать циклические ссылки

А как он их определял, кстати? Причём как он понимал, что эта ссылка никогда не будет использована?

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

A>Исходник этого GC был очень маленьким и работал предельно шустро, решая возложенные на него задачи. Писался он чтобы решить дилемму сложных многоуровневых циклических ссылок, которая то тут, то там возникала в проектах над которыми я работал.

Вот мой вопрос как раз в том — возможно или это принципиально. Т.е. не изменяя рантайм и компилятор — внедрить такой умный указатель с полноценным GC.

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

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

TB>А как он их определял, кстати? Причём как он понимал, что эта ссылка никогда не будет использована?

Ссылка может быть использована только тогда, когда на неё существует хотя бы один GCPtr<T>, который её "держит".

Параллельно GC строит граф зависимостей. Каждое создание GCPtr<T> — это создания вершины в графе. Если обьект, который создает GCPtr<T> сам лежит в GCPtr<T>, то между двумя вершинами создается ребро в графе. В определенные моменты происходит обход этого графа, определяляются циклы и иницируются их разрывы.

Вся это схема работала исключительно поверх подсчета ссылок, как слоенный пирог. Например, чтобы сделать разрыв цикла, GC делал определенным обьектам release, и когда счетчик ссылок достигал ноля, память освобождалась. Чтобы знать каким обьектам нужно помочь в разрыве цикла, держался граф.

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

A> В определенные моменты происходит обход этого графа

Аааа, ясно. А этот обход делался по принципу "стоп мир", или как-то по 4 итерации на каждый gc_new?

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

A>>По своей сути он был основан на подсчете ссылок, но умел при этом разрывать циклические ссылки

TB>А как он их определял, кстати? Причём как он понимал, что эта ссылка никогда не будет использована?

Тут можно перенять у .NET его модель корневых ссылок. Для каждого объекта ссылочного типа при его создании создается корневая ссылка, через которую осуществляется асинхронный мониторинг всех ссылок на объект. Когда CLR находит изолированный граф ссылок, она грохает все объекты, принадлежащие этому графу.

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

S>Вот мой вопрос как раз в том — возможно или это принципиально. Т.е. не изменяя рантайм и компилятор — внедрить такой умный указатель с полноценным GC.

Конечно возможно. Я еще хотел тогда опубликовать этот проект, но как-то руки тогда не дошли. А, видимо, зря.

Но там был один момент. В GCPtr<T> помимо самого указателя на обьект, нужно было передавать опциональный указатель на тот обьект, который его создает. Это было нужно для того, что получалось строить внутренний граф, который затем использовался для разрыва ссылок.

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

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

TB>Аааа, ясно. А этот обход делался по принципу "стоп мир", или как-то по 4 итерации на каждый gc_new?

Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0. Это состояние говорило о том, что возможно где-то есть циклическая зависимость и поэтому пора запустить GC.Collect(). Таким образом, это был полностью детерминированный GC с характеристиками сходными с ручным управлением памятью, но с удобством характерным для полноценного GC.

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

A>Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0. Это состояние говорило о том, что возможно где-то есть циклическая зависимость и поэтому пора запустить GC.Collect(). Таким образом, это был полностью детерминированный GC с характеристиками сходными с ручным управлением памятью, но с удобством характерным для полноценного GC.

А GC в отдельном потоке работал или в том же, что и деструктор?

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

R>А GC в отдельном потоке работал или в том же, что и деструктор?

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

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

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

Ну да, про детерминированность понятно, я потому и поинтересовался. А как по производительности — не сильно било?

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

R>Ну да, про детерминированность понятно, я потому и поинтересовался. А как по производительности — не сильно било?

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

S>Очень раздражает что пишет медленно и уходит от ответа.

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

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

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

Тем не менее, вам было интересно про мой опыт с GCPtr<T>, а если бы Shmj не задал вопрос, то вы про это никогда бы не узнали.

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

A>Конечно возможно. Я еще хотел тогда опубликовать этот проект, но как-то руки тогда не дошли. А, видимо, зря.

А это смотрели: https://hboehm.info/gc/ ?

Аналогично вашему работает?

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

A>Обход делался при каждом вызове деструктора GCPtr<T> в том случае, если счетчик ссылок для конкретного обьекта оставался больше 0.

Чёт квадратичная сложность получается.

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

S>А это смотрели: https://hboehm.info/gc/ ?

S>Аналогично вашему работает?

Смотрел и пытался использовал, не понравилось. Boehm GC — это вешь из другой вселенной и с совершенно другим подходом.

Не понравилось потому, что Boehm GC является недетерминированный сборщиком мусора, который работает с помощью сканирования содержимого выделенных блоков памяти на наличии указателей. Причем если какой-нибудь int где-нибудь на стеке случайно будет иметь такое же значение как и один из выделенных указателей, Boehm GC будет принимать это за чистую воду, думая что этот стек "ссылается" на блок. И поэтому такой блок может зависнуть навечно, и никогда не будет освобожден. Только из-за случайного совпадения какого-то int с каким-то указателем! Если это 128 байт, то ерунда, но представьте что-то более ёмкое.

Поэтому считаю, что Boehm GC годится только для определенных задач, которые не требуют каких-либо высоких характеристик и прогнозируемости поведения. Плюс реализация Boehm GC намного "жирнее" чем то, что делал я, где-то на порядок.

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

A>Поэтому считаю, что Boehm GC годится только для определенных задач, которые не требуют каких-либо высоких характеристик и прогнозируемости поведения. Плюс реализация Boehm GC намного "жирнее" чем то, что делал я, где-то на порядок.

Что-то не верится что все так просто — неужели ваше решение лучшее в мире и может из С++ сделать что-то даже лучше Rust-a? Наверное просто что-то не учли и оно не всегда работает.