Не нужно. Смысла особого в нем нету. Тормоза на выделение/удаление памяти больше времени займет. Да и для чего это нужно, если не секрет?

Тормоза на выделение/удаление памяти больше времени займет

Масдайный gc работает довольно таки шустро.

Да и для чего это нужно, если не секрет?

Прикладной цели нет, чисто интерес.

и еще

Тормоза на выделение/удаление памяти больше времени займет

Я полагаю, здесь просто нужна бистрая реализация memcpy.

Масдайный gc работает довольно таки шустро.

На фоне тормозящих прог, ну да (:

Логика вроде не сложная копирование памяти в новую непрерывную область, не?

g_slice_alloc частично решит проблему фрагментации. И как дефрагментировать? Придется ведь тогда менять значения указателей.

Логика вроде не сложная копирование памяти

Афаик, memcpy реализован как побайтное копирование.

Интересно, не знал. Но после прочтения возник вопрос: g_slice_alloc - это же только для выделения памяти, не для перераспределения?

И как дефрагментировать?

Например, после выполнения

realloc_all_like_dotnet_gc()

Это первая реализация, что пришла в голову.

На сях такое не сделать. Для сей не удастся реализовать копирующий сборщик мусора.

>> Масдайный gc работает довольно таки шустро.

О да, я около года поработал над сервером fragoria.ru. GC работает шустро только когда проц мощный, делать ему нечего и структура данных очень простая.

И да, возьми моно. Или ты думаешь в линуксе Си круче чем в винде и там есть GC? :)

> возвратится таблица соответствий: старый адрес - новый адрес.

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

Java же!

Кто-то должен был это сказать

>g_slice_alloc - это же только для выделения памяти, не для перераспределения?

Его использование уменьшит фрагментацию, но он не годится для строк и массивов, только для структур.

и че с этой таблицой делать?

А чем результаты поиска в гугле не устроили?

Для C компактифицирующий GC нереально сделать.

А это ничего, что в одном языке есть указатели, а в другом их в принципе нет? :-)

В .net gc переодически перераспределяет память, выделенную под конкретную программу, тем самым уменьшая фрагментрованность памяти. Как можно сделать такую же операцию на С в linux?

Предлагаю сначала хоть немного разобраться в основах .NET, C и управления памятью.

> И да, возьми моно.

В моно gc память не дефрагментирует, ЕМНИП.

Пока только экспериментальная поддержка есть http://www.mono-project.com/Compacting_GC в ветке 2.7

> И как дефрагментировать? Придется ведь тогда менять значения указателей.

Придется юзать не указатели, а более хитрую сущность, которая будет сама по себе жрать больше места и работать медленнее, зато позволит GC перекладывать объекты. Но это уже будет не C.

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

Для си++ можно сделать defragmentable_ptr<T> но проще пулы использовать.

И да, переменные на стеке рулят.

«дифрагментацией» памяти в С занимается ядро.

Чё?

>Чё? Гм. ну поищи в гугле slab allocator. или хотя бы buddy allocator чтоли.

>Придется ведь тогда менять значения указателей.
если дефрагментацией будет заниматься ядро - не придется.

если дефрагментацией будет заниматься ядро - не придется.

Чё?

Зачем это нужно? Очередная ловля блох?

А зачем?

Он же внутриядерный. Как он будет дефрагментировать то что выделено malloc'ом в юзерспейсе.

>Он же внутриядерный. Как он будет дефрагментировать то что выделено malloc'ом в юзерспейсе.

Продефрагментируй лучше мозги. без обид.

>> Продефрагментируй лучше мозги. без обид.

Какие умные анонимусы появились на лоре.

Я сделал млн malloc-ов по 1024 байта (1Г). Потом из каждых 4х блоков 1й оставил, а 2й,3й,4й - освободил. Итого: я использую 256М, а занят 1Г.

Как мне может помочь slab allocator?

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

менеджер память нужно свой писать

ляпнул чето. ваще то этим поставленную задачу не решить.

А это ничего, что в .NET указатели в принципе очень даже есть? И Си можно полноценно компилировать в .NET, между прочим.

>И да, переменные на стеке рулят.

Реквестирую std::string полностью на стеке!

И Си можно полноценно компилировать в .NET, между прочим.

Да, но GC в таком случае просто не будет работать.

Я сделал млн malloc-ов по 1024 байта (1Г).
Потом из каждых 4х блоков 1й оставил, а 2й,3й,4й - освободил.
Итого: я использую 256М, а занят 1Г.

Скорее всего, в случае современного х86 , 1Г занят не будет. Надо читать про аритектуру проца/OS на пердмет protected mode. Например начать отсюда http://en.wikipedia.org/wiki/Protected_mode. Краткая мораль: цифра которую вы видите по printf(«%X»,pointer); не имеет прямого отношения к физическому положению в памяти.

Прочь руки испачканные GC от системного программирования :).

>> Скорее всего, в случае современного х86 , 1Г занят не будет.

Будет. я даже проверил.

sbrk при малоках отодвигает границу, а т.к. страница = 4к, то ни одна из страниц не освобождается.

> Да, но GC в таком случае просто не будет работать.

Будет. Не говорите глупостями.

Да, но GC в таком случае просто не будет работать.

Будет. Не говорите глупостями.

Не будет. Как ты вообще себе представляешь автоматическое управление памятью, выделенной в С?