Ответ на самый верхний пост -- можно, это делает либа под названием boehm gc

На днях я ее ковырял, было интересно как же она работает. Оказалось - просто. Она анализирует стек. Во всех архитектурах в стек пушается только числа фиксированной ширины, на i386 это 4байта, на 64 архитектуре 8... В стеке хранятся адреса возвратов и локальные переменные. И если локальная переменная - указатель, то можно посмотреть куда он указывает, а если есть список ранее выделеный участков памяти, то можно просмотреть есть ли в стеке указатель на этот участок.
вот так она и работает.

Ну и плюс куча извращений и костылей по получаения адреса стека одного потока из другого.

Это вы меня спрашиваете??? Это я вас хочу спросить.

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

Мне кстати удавалось ее обмануть без регистров. Она, помимо стека, анализирует (по всей видимости, рекурсиво) указатели, которые там хранятся. То есть если заалоцировать указатель:

int **p = (int **) GC_MALLOC(sizeof(int *));

и потом заалоцировать еще блок памяти, присвоив его этому указателю

(*p) = (int *)GC_MALLOC(50);

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

но если мы заалоцируем массив и попытаемся его использовать:

int **p = (int **) GC_MALLOC( 10*sizeof(int *) );
p[5] = (int *) GC_MALLOC( 50 );

То либа "не видит" все, что дальше p[0].


mayton В Java декремент счётчика ссылок происходит при потере scope. Это логично. Это надёжно. Вышел из скоупа - значит референс потерял -1
Тут корректней было бы говорить о конкретном GC конкретной jvm. Только в оракловкой jvm их вроде 3 штуки разных. В проекте cacaovm их две, одна из которых - boehm. gcj тоже на boehm базируется. К тому же, даже если в яве подсчет ссылок есть, он служит для оптимизации, потому что бывают еще и циклические ссылки, и там подсчет бессилен.

насчет того, что компилятор может самовольно сделать так, как вы пишите, засунув самовольно указатель - в регистр. gcc так не делает, по крайней мере с ключиком -O2
Но если с какими-то ключиками он будет так делать, то тогда надо будет использовать модификатор volatile там, где он нужен. Однако, насколько знаю, самовольно регистры он никогда не использует по той причине, что даже в однопоточной программе это может приводить к трудноуловимым ошибкам.

Если у нас есть указатель int* x; то нет никакой гарантии, что в программе нету int **y, который в какой-то момент времени начнет указывать на x. И если компилятор самовольно засунет x в регистр, то это будет совсем не то, что хотелось программисту, поэтому компилятор так не делает (возможно, ключик у него все же есть какой-то). поэтому, если такая оптимизация руками не включена, то можно не опасаться, ну а если эту оптимизацию включили - ссзб, ибо она даже по документации dangerous.

Хм, проверил - действительно, потенциальная проблема имеет место.

Я думаю, этот неочевидная то ли фича то ли баг лежит на совести программиста. Странно, но по этой проблеме навскидку вообще ничего не нагугливается.

Волатильной в этом примере должна быть tmp. Делаем:

int* volatile tmp = pa;

и тогда получаем:




х86 ассемблер не мой конек, но похоже, теперь все ок.

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

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

получается, что boehm убирает одни проблемы, но зато вносит другие. И так и знал, что подвох обязательно будет. :((

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

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

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

sherzod_,

1. указатели на указатели либа ловит, но с ограничениями (см 13665184 где я описал этот случай), на то он mark&sweep.

2. Регистровые указатели вообще сомневаюсь что можно поймать, поэтому тут надо быть осторожным

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

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

5. наличием указателей на функции, на функции-члены, полиморфизмом, кастами
Для плюсов там есть плюсовый аллокатор.

Что же касается указателя на функцию, то функции не хранятся в хипе. GC смотрит куда указатель указывает -- не в хип. И это все, что ему надо. Если он встретил что-то, что указывает не в его хип -- это либо чужой указатель, либо вообще не указатель, его трогать не надо и не надо никак обрабатывать. Точно так же адреса возврата gc не будет никак обрабатывать, потому что они не указывают на его хип.

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

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

авторЗа исключением того, что все же эту библиотеку вряд ли можно с разумными затратами на написание кода использовать прямо в программах на С и С++.

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

Насчет цены и переносимости. Как оно работает с большим хипом и большим количеством обьектов - я не знаю. Насчет переносимости -- этот gc портрован на много разных архитектур. Если заглянуть в его configure, там даже амига есть, есть упоминание архитектур в которых стек растет вверх а не вниз...

я с этим gc познакомился чуть ближе, когда пытался откомпилить cacaovm для qnx6 под i386. В портах оказалась только потоко-опасная версия. Пока мне не удалось это сделать, т.к. в qnx6 некорректно работает получение sp другого потока. Пока у меня не вышло с этим ничего сделать, и я на это забил, но думаю вернутся по свободе. Но это - исключение. Этот gc уже портирован на большинство известных архитектур большинства ОС. Если же надо что-то редкое, то все равно проблемы неизбежны. Не с одним - так с другим. Портабельность и С++ - вещи малосовместимые, к сожалению.

авторупаковка в целое не обязана быть представлением адреса (вспомните про знаковые).
Насколько я понял, вы считаете, что если мы упакуем аддрес в signed, то его побайтовое предстваление будет другим. На i386 и amd64 это не так. побайтовые представления совпадают. И я уверен, что на большинстве архитектур - тоже.

Ниже прога, сделаная "на скору руку", как доказательство.




На х64 вывод такой:

выводsizeof(void*)=8
sizeof(long)=8
0x10 0xa0 0xdd 0x1 0x0 0x0 0x0 0x0
0x10 0xa0 0xdd 0x1 0x0 0x0 0x0 0x0
value=-1
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff


Если вы будете ее тестить на х32 то у вас sizeof(void*) будет равно 4, и тогда вам надо распечатывать и сравнивать по 4 байта а не по 8, и возможно вместо long подставить что-то четырехбайтовое (если long таковым не будет).

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