Кто-нибудь с этим разбирался?
viewtopic.php?f=2&t=684&start=885#p53130
Может быть, Serge разъяснит, что там за такой очень хитрый менеджер памяти
viewtopic.php?f=2&t=684&start=930#p57580
там суть в том, что система даёт памяти больше, чем есть. А если в неё произойдёт запись, то начинаются PageFault-ы.
Выделение памяти
При int 40h разве не происходит записи в стек следующего адреса? Как при call? Вроде как происходит.Кто-нибудь с этим разбирался?
viewtopic.php?f=2&t=684&start=885#p53130
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!
Вроде как ещё и флаги сохраняются. То-есть 8 байт в стеке.
Это спекулятивно оптимистичное поведение. Система позволяет программе зарезервировать из доступных адресов в userspace столько, сколько она просит. Физическая память выделяется после, страницами при обращении к адресам. Если в какой-то момент физической памяти не хватит, программа завершится со страничной ошибкой.там суть в том, что система даёт памяти больше, чем есть. А если в неё произойдёт запись, то начинаются PageFault
Кстати, винда тоже так делает, но у неё есть условно бездонный файл подкачки: не хватает — увеличивает.
Главный вопрос: в каких случаях программа берёт память и не использует её? Или конкретней: зачем намэтот баг эта сомнительная фича?
Главный вопрос: в каких случаях программа берёт память и не использует её? Или конкретней: зачем нам
Pathoswithin
Практически во всех программах, сложнее "Hello, world!" Там, кстати, тоже. Например программа рисует клиентскую область в битмап, чтобы избежать ненужных перерисовок. Если этот битмап фиксированного размера под текущий размер окна, его надо будет пересоздавать при растягивании окна. В этом случае лучше зарезервировать под битмап буфер максимально необходимого размера и управлять страничной памятью вручную.
Практически во всех программах, сложнее "Hello, world!" Там, кстати, тоже. Например программа рисует клиентскую область в битмап, чтобы избежать ненужных перерисовок. Если этот битмап фиксированного размера под текущий размер окна, его надо будет пересоздавать при растягивании окна. В этом случае лучше зарезервировать под битмап буфер максимально необходимого размера и управлять страничной памятью вручную.
Ну надо сделать проверку, чтобы система хотя бы не выдавала больше памяти, чем есть на данный момент.
GerdtR wrote:При int 40h разве не происходит записи в стек следующего адреса? Как при call? Вроде как происходит.
Да при чём здесь стек приложения?Pathoswithin wrote:Вроде как ещё и флаги сохраняются. То-есть 8 байт в стеке.
Вот код с вершиной стека в нуле
Code: Select all
ORG 0
BITS 32
; --------------------------- ;
MENUET01 db 'MENUET01'
version dd 1
program.start dd START
program.end dd END
program.memory dd END
program.stack dd 0
program.params dd 0
program.path dd 0
; --------------------------- ;
START:
mov eax, 15
mov ebx, 3
int 64
mov eax, -1
int 64
; --------------------------- ;
END:
Pathoswithin
Система не может выделить памяти больше, чем есть. Просто не надо путать резервирование адресов в userspace процесса и физ. память всей системы.
Система не может выделить памяти больше, чем есть. Просто не надо путать резервирование адресов в userspace процесса и физ. память всей системы.
Если я правильно понимаю, по адресам памяти от FFFFFFFFh и ниже проецируется видеобуфер и доступ туда открыт всем программам.
Serge
Я не путаю, я спрашиваю проверяет ли система количество свободной физической памяти в момент резервирования адресов в userspace процесса?
Serge
Я не путаю, я спрашиваю проверяет ли система количество свободной физической памяти в момент резервирования адресов в userspace процесса?
Pathoswithin
Нет, не проверяет. Это лишнее. Некоторые применения 68.12 не требуют немедленного выделения физической памяти. Например открытие расшаренной памяти, загрузка длл, маппинг текстуры в драйвере. Широко применяемая malloc традиционно запрашивает память блоками большого размера при этом реально может использоваться 10%. Под стек в приложениях (binutils, Fplay и все остальные с newlib) резервируется 2Mб и т.д.
Нет, не проверяет. Это лишнее. Некоторые применения 68.12 не требуют немедленного выделения физической памяти. Например открытие расшаренной памяти, загрузка длл, маппинг текстуры в драйвере. Широко применяемая malloc традиционно запрашивает память блоками большого размера при этом реально может использоваться 10%. Под стек в приложениях (binutils, Fplay и все остальные с newlib) резервируется 2Mб и т.д.
А если нетPathoswithin wrote:Если я правильно понимаю
Spoiler:
Code: Select all
ORG 0
BITS 32
; --------------------------- ;
MENUET01 db 'MENUET01'
version dd 1
program.start dd START
program.end dd END
program.memory dd END
program.stack dd 0
program.params dd 0
program.path dd 0
; --------------------------- ;
START
mov [0xFFFFFFFF], dword 0
mov eax, -1
int 64
; --------------------------- ;
END
Spoiler:
General protection fault это не page fault. Попробуй FFFFFFF8h.
Вот возьми сам и попробуй. Тебе полезно будет. А я результат знаю.
Pathoswithin wrote:проверяет ли система количество свободной физической памяти в момент резервирования адресов в userspace процесса?
Serge, ты так и не сказал, как можно решить эту проблему. Посмотри ещё раз на картинку в посте viewtopic.php?f=2&t=684&start=930#p57580 и скажи, как нужно в этом случае действовать приложению, чтобы не нарваться на PageFault. Ведь, как видно, памяти выделено явно больше, чем имеется, только приложения об этом не знают. Если можно, то пример кода, как можно обойти такую проблему.Serge wrote:Нет, не проверяет. Это лишнее.
Who is online
Users browsing this forum: No registered users and 9 guests