Доброго времени суток!
Хочется обсудить такую вещь...
Допустим, имеется некоторая система, которая подразумевает автоматическое управление памятью (CLR, как наиболее подхоящая аналогия). Точнее, ее еще не имеется — важный фактор
Для создание этой системы в том числе нужно разработать менеджер памяти со сборщиком мусора. В общем-то, алгоритмы известны, думаю, гугл тут легко поможет.

А теперь собственно вопросы.
Каким образом проверить работоспособность и производительность такого абстрактного менеджера памяти? Если нет еще той системы, к которой его можно "прикрутить" и просто погонять на обычных задачах.

Если есть несколько реализаций, по каким критериям стоит выбирать между ними? Или можно заранее по каким-то объективным критериям определить наилучший алгоритм?

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

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

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

MK>Каким образом проверить работоспособность и производительность такого абстрактного менеджера памяти? Если нет еще той системы, к которой его можно "прикрутить" и просто погонять на обычных задачах.

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

MK>Если есть несколько реализаций, по каким критериям стоит выбирать между ними? Или можно заранее по каким-то объективным критериям определить наилучший алгоритм?

Тогда только он бы и остался, зачем остальные

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

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

SH>Производительность зависит от задач и от того, что у нас узкое место — память или время. Например, если памяти полно, можно её вообще не освобождать Если всё узкое — то где и насколько можно пойти на компромисс..

Кстати, если система переносимая, то "it depends", а вообще, даже если память почти не ограничена, но система работает безостановочно, то если ее просто не освобождать, она все равно рано или поздно закончится... Т.е. CLR тут даже не самый удачный пример — хотя, с другой стороны, известных ОС в которые встроен сборщик мусора как-то не припоминается...
В таком случае, переведем вопрос на оценку "кривости" реализаций и работоспособности Т.е. интересен сам принцип тестирования — каким образом отследить возможные баги?

SH>Тогда только он бы и остался, зачем остальные

Тем не менее, не "от башни" же их выбирают разработчики?

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

MK>Кстати, если система переносимая, то "it depends", а вообще, даже если память почти не ограничена, но система работает безостановочно, то если ее просто не освобождать, она все равно рано или поздно закончится...

Это тоже в ходит в "от задач". Например: если система заканчивает свою работу быстро или, если она выделяет память только в самом начале, или, если краш и перезапуск — это вполне нормальная ситуация.. Ну может ещё пара случаев бывает.

MK>Т.е. CLR тут даже не самый удачный пример — хотя, с другой стороны, известных ОС в которые встроен сборщик мусора как-то не припоминается...
MK>В таком случае, переведем вопрос на оценку "кривости" реализаций и работоспособности Т.е. интересен сам принцип тестирования — каким образом отследить возможные баги?

А чем менеджер памяти отличается от любой другой библиотеки? Тестами, покрытием, юнит-тестами.

SH>>Тогда только он бы и остался, зачем остальные
MK>Тем не менее, не "от башни" же их выбирают разработчики?

Я имел ввиду, что нет "лучшего всегда". Какой лучше зависит от стоящих задач. Если нужен универсальный.. Тогда не знаю Думаю, что разные универсальные на разных задачах дадут разные результаты.

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

MK>Доброго времени суток!
MK>Хочется обсудить такую вещь...
MK>Допустим, имеется некоторая система, которая подразумевает автоматическое управление памятью (CLR, как наиболее подхоящая аналогия). Точнее, ее еще не имеется — важный фактор
MK>Для создание этой системы в том числе нужно разработать менеджер памяти со сборщиком мусора. В общем-то, алгоритмы известны, думаю, гугл тут легко поможет.

MK>А теперь собственно вопросы.
MK>Каким образом проверить работоспособность и производительность такого абстрактного менеджера памяти? Если нет еще той системы, к которой его можно "прикрутить" и просто погонять на обычных задачах.

MK>Если есть несколько реализаций, по каким критериям стоит выбирать между ними? Или можно заранее по каким-то объективным критериям определить наилучший алгоритм?

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

MK>И наиболее "философский" вопрос напоследок — имеет ли вообще право на существование подобная модель "абстрактного менеджера памяти", или все же нужно разрабатывать всю систему, а только потом методом "научного тыка" и стресс-тестов смотреть что получилось и ловить потом баги сразу по всей системе?


Мне кажется что все garbage collection слишком навороченны.
Проще использовать что то наподобии этого:
http://swapped.cc/halloc/

(Я могу прислать мою разработку аналогии halloc)
можно добиться и leak detection и garbage collection и memory allocation / freeing tracking, короче чем проще система
тем меньше в ней ошибок.