El Sanchez

Full Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата: Видимо, действительно с /LARGEADDRESSAWARE он собран. А почему не распакует архивы 7z, rar, zst со словарем 2 Гб, в том числе и на 64-битных ОС, Игорь должен смотреть, не нормально это. | lelik007, это нормально, для x86-программ 2ГиБ одним куском вы не получите никак, хоть с флагом, хоть без него, хоть rar, хоть не rar, пофиг. Итак, варианты: 1. x86-система, x86-программа без LAA: 2ГиБ виртуального адресного пространства (диапазон адресов 0x0 - 0x7fffffff). Почти в конце диапазона по адресу 0x7ffe0000 лежит расшаренная для всех x86-процессов системная структура KUSER_SHARED_DATA, кэширующая часто используемые данные из ядра, ибо часто переключаться из юзермода в кернелмод для получения этих самых данных слишком дорогое удовольствие. Адрес структуры фиксирован, память для неё выделена куском в 64КиБ (диапазон адресов 0x7ffe0000 - 0x7fff0000), кусок 2ГиБ ну никак не влезет в оставшееся место 0x7ffe0000/*от базового адреса KUSER_SHARED_DATA*/ - 0x0/*до начала пространства*/ = 0x7ffe0000 = ~1,999ГиБ. А ведь ещё в этом диапазоне адресов образ программы (пусть будет со стандартного адреса 0x400000), стеки потоков, куча процесса, системные библиотеки (где-то около 0x77xxxxxx ntdll.dll, остальные ниже). Так что пространство ниже 2ГиБ фрагментировано и реальный максимум куска может быть что-то около 1,45ГиБ. 2. x86-система с /3GB/USERVA/increaseuserva, x86-программа без LAA: то же, что и п.1, т.к. нужен LAA бит в проге. 3. x86-система с /3GB/USERVA/increaseuserva, x86-программа с LAA: 3ГиБ виртуального адресного пространства (диапазон адресов 0x0 - 0xbfffffff). То же самое, что и п.1, плюс халявный 1ГиБ (0xbfffffff - 0x7fff0000 /*до верхней границы KUSER_SHARED_DATA*/ = 0x40000000 = 1ГиБ). Этот кусок будет уже фрагментирован, когда вы захотите его использовать, по верхним адресам где-то с 0xbffb0000 и выше уже будут PEB, TEB процесса, так что реальный максимум куска может быть что-то около 0,999ГиБ. 4. x64-система, x86-программа без LAA: 4ГиБ виртуального адресного пространства (диапазон адресов 0x0 - 0xffffffff). То же самое, что и п.1, т.к. хоть и становится доступен диапазон адресов 0x80000000 - 0xffffffff, программа без LAA усекает указатель до дефолтной адресации 0x0 - 0x7fffffff. 5. x64-система, x86-программа c LAA: 4ГиБ виртуального адресного пространства (диапазон адресов 0x0 - 0xffffffff). То же самое, что и п.1, плюс халявные 2ГиБ (0xffffffff - 0x7fff0000 /*до верхней границы KUSER_SHARED_DATA*/ = 0x8000FFFF = чуть больше 2ГиБ). Этот кусок будет уже фрагментирован, когда вы захотите его использовать, хз чем, так что реальный максимум куска может быть что-то около 1,99ГиБ. На тестовом 2Gb.zst 7za запрашивает 0x80040000, что больше реального максимума куска и теоретического 0x8000FFFF. Если б не KUSER_SHARED_DATA, то реальный максимум расширился бы до самого высокого базового адреса системных библиотек (0x77xxxxxx ntdll.dll выше всех), хватило бы для цельного куска примерно до 2,12ГиБ, а так гуляй, Вася. Цитата: rar.exe x86 распаковывает файл .rar со словарем 2 Гб на 64-битной ОС с 32 Гб оперативной памяти | lelik007, rar пытается выделить кусок размером 0x80000000 = 2ГиБ, естественно, у него это не получится никак. При неудаче rar вместо того, чтобы сдаться, как 7zip, получает несколько несмежных кусков общим размером с требуемым по своему алгоритму (максимум 32 куска, минимальный размер куска 4МиБ). Самый первый кусок максимально возможного размера, который удастся получить. На тесте с 2Gb.rar запрошенный кусок в 0x80000000 байт в итоге разбился на 2 куска 0x7C000000 и 0x04000000. P.S. Павлов может забить, может сделать как в rar, может использовать AWE, который требует такой же привилегии, как и для Large Pages, а значит админ права и вой дебилов. |