Извиняюсь если спрашиваю очевидные вещи, но: вызываю с MEM_RESERVE на дофига памяти, после прога узнает сколько ей реально требуется и - MEM_COMMIT сколько надо. Вопрос: как сократить НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство?
Етить, похоже не понятно написал. У Free два флага: MEM_DECOMMIT и MEM_RELEASE. DECOMMIT освобождает выделенную память. RELEASE освобождает ВСЁ пространство адресов. Мне надо УМЕНЬШИТЬ пространство адресов до необходимых размеров, например было 512МБ, а стало 10КБ - не выделенной памяти, а непрерывного адресного пространства.
IMHO можно вообще не сокращать НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство: - если далее нет XXXAlloc, то всё ОК. - если далее есть XXXAlloc, то всёравно прога должна учитывать вариант, когда вся MEM_RESERVE будет сделана MEM_COMMIT, инече зачем так много MEM_RESERVE?
Резон: делаю VirtualAllocEx (512MB) MEM_RESERVE в WarCraftIII, гружу следующую миссию - варчик вылетает.
LocTb >"как сократить НЕПРЕРЫВНОЕ ЗАРЕЗЕРВИРОВАННОЕ пространство?" >"RELEASE освобождает ВСЁ пространство адресов." Поэтому никак. S_T_A_S_ уже ответил, что можно ничего не сокращать, т.к. зарезервированное пространство "каши не просит" и раз ты его выделил, то наверное не от балды, а в расчете на то что оно может заполнится. Вот и рассчитывай дальнейшую логику из того что оно заполнено. А общих подходов может быть несколько. Самый простой это тот о котором ты говоришь. Прикинули сколько максимум может понадобиться и зарезервировали один раз. Если пожадничал и оказалось нужно больше, то либо выдавай exception, либо резервируй новый увеличенный блок и переписывай все в него. Если и пространство сэкономить хочется и не переписывать данные, тогда переходим к резервированию блоками, например по 1Мб (минимум 64 кБ, но уж никак не 10). Здесь опять два случая. Если больше никаких явных или скрытых аллоков не делается, то в итоге все блоки образуют один непрерывный массив. Поэтому с данными можно работать как обычно, а усложняется только управление выделением и освобожденим блоков памяти. Если же между твоими блоками данных, может втиснуться "посторонний", то придется усложнять и управление памятью и данными, т.е. если с ними нужно работать как с массивом или стримом, то придется учитывать переходы адресов между блоками.
leo Большое спасибо, а то уж стал думать что с ума схожу- именно такие мысли и приходили в голову. Просто думал есть аналогия Realloc для резервирования. Остановился на таком методе- резервирую дофига, после выделив сколько надо- резервирую и выделяю в новом месте и копирую туда данные, старый большой блок - RELEASE. Если есть лучшие идеи -поделитесь пожалуйста.
LocTb > "Если есть лучшие идеи - поделитесь пожалуйста" Чтобы были идеи нужно уточнить задачу. Из слов "гружу следующую миссию" можно сделать вывод, что тебе нужно последовательно выделять несколько блоков памяти заранее неизвестных размеров. Но тогда вопрос: а почему для каждого блока нужно делать отдельный резерв. Почему нельзя писать все блоки в одно пространство: делаешь один большой резерв, а затем только commit. И еще не совсем понятно как происходит загрузка и почему размер становится известным только в конце.
leo Да нет, я имел ввиду вот что: зарезервировав много памяти, я в игре жму "продолжить", и после трещания винта у меня stack overflow. С проблемой- разобрался, я просто поприбивал у некоторых страниц PAGE_GUARDE. >"Почему нельзя писать все блоки в одно пространство: делаешь один большой резерв, а затем только commit" Именно так и делаю. >"И еще не совсем понятно как происходит загрузка и почему размер становится известным только в конце" Написал прогу типа ArtMoney, оптимизированную для XP/2003- вот по-этому и не знаю сколько надо вначале памяти. PS.: Хоть и всё работает, но теперь вначале резерв = 64МБ
