I do not expect we will ever “add GC to Rust” as it exists in other languages, or that we will recommend people use it as an “escape hatch” around the borrow checker
Я так понимаю что лодочник устал ловить учтечки памяти и микроменеджить Weak’и при написании графов, хочет попробовать альтернативный подход до ума довести.
Я только пока не очень понял как у этой штуки с влиянием на внешний мир - т.е. если я возьму библиотеку, использующую внутри себя такой gc вместо Rc’шек, смогу ли я снаружи это заметить или мне будет полностью все равно как оно реализовано? Паузы долгие и всякое такое.
Я думаю тут вопрос в том, будет ли она выдавать наружу GC-указатели, или, например, пользователю библиотеки отдаются копии информации в узлах графа, который положен в GC.
Как эксперимент не плохо, но в реальной жизни я пока не хочу это видеть. Может когда увижу использование в реальной жизни и заимею необходимость передумаю. Но пока чем больше с растом я работаю тем больше прихожу к выводу что нужно использовать новые подходы и они наоборот только делают код проще. Под новыми подходами, имею ввиду не приносить в язык практики работы из других языков.
Возьмем один из его описанных кейсов(что я недавно переосмыслил кстати). Есть объект “А” который содержит в себе объекты, которые хранят внутри себя ссылку на родителя(объект А), по средствам которого они могут общаться между собой. До раста я любил такие вещи делать, но много где встречал мысль, что данный подход не есть хорошо. Ведь идет не очевидная связь. Да и к тому же, увеличивает сложность тестирования. Но если в других языках можно мокать, то в расте это дело не совсем удобно делать(все равно придется создавать объект А целиком).
В начале тоже начал делать решение используя Rc. Но тестирование прям не давало покоя, не нравилось мне создавать большой объект, пусть даже используя default метод. И в итоге пришел к выводу что лучше делать отдельные сущности, которые отвечают только за свою работу а уровнем выше разворачивать паттерны “command” и “facade” . И в итоге получилось намного чище, понятнее, а главное более удобное для тестирование приложение.
Правда сейчас когда писал это сообщение, подумал что единственное где возможно GC понадобится, это при написание GUI. Так как раз по идеи RC используется в большом кол-ве и не совсем удобно постоянно unwra-пить
Ну а ты бы как хранил граф с циклами?
Сейчас там где требуются небольшие графы, допустим какая то древовидная структура. Я использую принцип бд, это когда мы имеем массив id parent и соответветственно при считывании разворачиваем в HashMap, в котором children хранят массив id элементов, а ключ непосредственно id. Да мне приходится делать О(1) для поиска элемента. Но я думаю это не сильно критично когда у тебя небольшой кусок данных.
Ну а для больших вещей или для большого удобства можно использовать уже готовые библиотеки какие ни будь. Типа этой
ну если эта GC будет где то сбоку работать только над ограниченным пространством структур которым нужны циклические ссылки…
почему нет, пусть коптит себе.
Мои главные опасение, что понабегут люди которые начнут это использовать везде, где это вообще не нужно. С одной стороны хорошо, что раст сможет охватить больше народу, но с другой, нужно ли нам их труд полученный таким образом. Все таки каждый инструмент используется для свои вещей. А сейчас это похоже, как если бы к молотку изолентой примотали отвертку. Вроде идея раста раз компилится значит на 99% не упадет в рантайме, если ты конечно unwrap-ами не пользуешься. И нет ни каких утечек памяти. А в итоге получается, спасибо, но нам как то с GC интереснее жилось.
Ну во-первых, фрагментация экосистемы - это соображение, которое многократно озвучивалось, так что я уверен, что для GC будут искать решение, которое позволит сочетать разные способы управления памятью.
Во-вторых Rust не гарантирует отсутствие утечек.
Я и не говорил что гарантирует, но в большей степени защищает тебя от этого момента нежели при использовании GC. Ну а про то что GC нужен, ну не знаю, по мне если и нужен то на уровне компилятора. Могу ошибаться, но подход через библиотеку не будет столь оптимальным. Ладно посмотрим куда все это выльется 
Это больше похоже на реальную причину разработки сборщика мусора. В графах он конечно тоже может пригодиться, но есть масса способов обойтись и без него.
Насколько я понял, прям реальная причина разработки этой библиотеки просто в том что Лодочнику очень хочется поиграться с новым Pin API и это же основное отличие от прошлых экспериментов с реализацией GC библиотек.
Господа, почитал про Pin, но не уразумел в чём его смысл? просветите про какое такое перемещение идёт речь ?
в результате перераспределения памяти (рост структуры)?
дефрагментации кучи планировщиком (такое вообще бывает)?
Про перемещение которое move, инвалидация памяти из которой значение скопировано куда-то ещё.
Посмотрел пример и не понимаю его, зачем Box ещё в Pin оборачивать, что страшного произойдёт при move Box, это же просто передастся другой переменной указатель на объект в куче, почему там инвалидация памяти будет?
Чтобы нельзя было содержимое Box переместить чем-нибудь вроде mem::swap().
Там в описании это есть:
since data can be moved out of
&mutandBoxwith functions such asswap, which causes their contents to swap places in memory, we need dedicated types that prohibit such operations.
Инвалидируется объект, который перемещается, а не куда он указывает.
При перемещении Box структура на стеке больше не может быть использована, т.к. есть другая копия этой структуры, которая управляет выделенной памятью.
Можно тупо использовать гарбаж коллектор от hanns boehm (boehm gc). По идее если указывать вж 'static, то оно будет работать.
работает он по следующиему принципу. Если мы объявляем стековую переменную и берем ее аддрес - мы получаем адрес в стеке, имея этот аддрес и зная его же в main() мы получаем диапазон в котором наш rootset. От него отплясываем, дальше куча магии - и все работает, даже в многопоточном варианте.
Бём консервативный, поэтому он не очень интересен. При его использовании много ресурсов по сути утекает.
Shifgrethor (так и хочется назвать его Шифером) - точный (precise) сборщик мусора.
Новые части: