Я создал класс тома (называемый VoxelVolume) с самоорганизующимся управлением памятью, поскольку сборщик мусора в C # не предоставил хорошего механизма для управления содержимым тома для отображения, отмены сопоставления и переназначения. Хотя я мог бы использовать механизмы виртуальной памяти, проблема в том, что файлы часто слишком велики, чтобы помещаться в файл подкачки, и я не хочу заставлять пользователей увеличивать размер файла подкачки.
В настоящее время эта система работает достаточно хорошо, и нет проблем с отсутствием ресурсов и исключений OutOfMemoryException, поскольку исключение InsufficientMemoryException с использованием MemoryFailPoint работает достаточно хорошо. Это все тесты в 32-битной системе WinXP с 2 ГБ оперативной памяти.
Запуск того же механизма в 64-битной системе с 32 ГБ основной памяти также работает хорошо, но при запуске приложения MemoryFailPoint внезапно выдает исключение, хотя 24 ГБ основной памяти все еще свободны. Еще один момент: когда MemoryFailPoint срабатывает один раз, он срабатывает каждый раз, и от него нет шансов избавиться.
То, что я до сих пор читал, что есть маленький объект и куча больших объектов (SOH и LOH). Но только для SOH GC по-настоящему заботится, и я могу освободить SOH от неиспользуемых объектов, применяя GC.Collect () и GC.WaitForPendingFinalizers. Очевидно, что MemoryFailPoint - единственный способ получить немного контроля над LOH, но поскольку в системе достаточно памяти, я не вижу причин, по которым MemoryFilePoint должен срабатывать.
Есть ли здесь какой-нибудь опыт использования MemoryFailPoint?
Спасибо за вашу помощь
Martin