I think maybe our concerns are overblown. I wrote a test program that checks the total available memory, allocates 3/4 of the available memory (without AVT_Lock, FALSE), frees it without unlocking the memory and then allocates half of the available memory as unlocked memory (AVT_Lock, FALSE). Apparently, failing to Unlock memory doesn't affect it's availability to the system. I'm guessing that it just affects virtual memory and swapping.ChrisH wrote:A question that has not yet been asked is *why* can't OS4 automatically unlock memory when it is freed? This would at least avoid a nasty "locked memory" leak. I can imagine that implementing this might increase memory overhead slightly, but that seems like a small price to pay.
Doing that would *not* remove the need for an improved API, but it would reduce the urgency of it.
Memory allocation
Re: Memory allocation
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Memory allocation
Did you allocate it as MEMF_SHARED though? Earlier it was said that only MEMF_SHARED memory would be locked by default. (most people won't be using this)xenic wrote:I think maybe our concerns are overblown. I wrote a test program that checks the total available memory, allocates 3/4 of the available memory (without AVT_Lock, FALSE), frees it without unlocking the memory and then allocates half of the available memory as unlocked memory (AVT_Lock, FALSE). Apparently, failing to Unlock memory doesn't affect it's availability to the system. I'm guessing that it just affects virtual memory and swapping.ChrisH wrote:A question that has not yet been asked is *why* can't OS4 automatically unlock memory when it is freed? This would at least avoid a nasty "locked memory" leak. I can imagine that implementing this might increase memory overhead slightly, but that seems like a small price to pay.
Doing that would *not* remove the need for an improved API, but it would reduce the urgency of it.
Re: Memory allocation
I don't think you understand what page locking actually is.xenic wrote:Apparently, failing to Unlock memory doesn't affect it's availability to the system. I'm guessing that it just affects virtual memory and swapping.
Is the wiki really that bad or is this just an understanding problem?
ExecSG Team Lead
- nbache
- Beta Tester
- Posts: 1744
- Joined: Mon Dec 20, 2010 7:25 pm
- Location: Copenhagen, Denmark
- Contact:
Re: Memory allocation
It's not *that* bad, but I'd still suggest some resequencing. For instance:ssolie wrote:Is the wiki really that bad or is this just an understanding problem?
(styles/layout reproduced as closely as possible).Locking System Memory
The LockMem() function is used to explicitly lock a memory block. This function will make sure your memory block is not unmapped, swapped out or somehow made inaccessible. Use this function wisely. If there is no good reason to lock memory then do not do it. It will prevent the memory system from optimizing memory layout and may lead to poor performance.Before deallocating the memory is must be unlocked as well.Code: Select all
IExec->LockMem(mem, 1000);
By default, MEMF_SHARED and MEMF_EXECUTABLE memory is locked when allocated and must be explicitly unlocked before freeing. Always refer to the autodocs of any memory allocation functions to determine whether explicit unlocking is required.Code: Select all
IExec->UnLockMem(mem, 1000);
Do not forget to UnlockMem()
Failure to unlock memory will have adverse affects on the memory system. Locked memory pages cannot be moved so the system cannot optimize the layout of locked memory pages.
All I did was move the first paragraph ("By default, ...") further down. I think this presents the concepts in a more logical sequence.
Best regards,
Niels
Re: Memory allocation
Yes it was MEMF_SHARED. You can try the same experiment yourself; it only takes a few minutes to write some code that allocates/deallocates memory.chris wrote: Did you allocate it as MEMF_SHARED though? Earlier it was said that only MEMF_SHARED memory would be locked by default. (most people won't be using this)
AmigaOne X1000 with 2GB memory - OS4.1 FE
Re: Memory allocation
I'm still not very comfortable with this "definition":
The memory is always *accessible*, just perhaps not at this precise clock cycle, which is why you want to use locked memory in interrupts and likewise. Just strike the "somehow made inaccessible" bit. Any driver developers should be assumed to have some more knowledge, and the ones that don't are not helped by the explanation.
My suggestion:
Furthermore, I do think there are some of us that don't exactly know what "page locking" means (especially since we can never lock or unlock *pages*, only memory, at least according to the name of the functions: Lock/UnlockMem).
This is how I understand it (I hope I'm conceptually correct, I haven't bothered with page size and stuff):
If we allocate and lock 16 Mbyte of memory, and then free it without unlocking, the system will get its 16 Mbyte back. However, the system cannot swap or move these 16 Mbyte. Nonetheless, these 16 Mbyte are available for any new allocations. Any 1 Mbyte allocations will eventually get a piece of these 16 Mbyte. But, now imagine the system running out of memory. The system tries to swap out memory, but the big 16 Mbyte chunk of memory cannot be swapped since it's locked, even though not all of the 16 Mbyte of it are used.
Did I get it right?
I think I made some misplaced quotes in the beginning of the thread which lead some to believe that locked memory can't be freed -- which it can.
Furthermore, I also think nbache's change suggestion is good.
This is not a definition. I would call "somehow" a random event, which a computer system really can't do.This function will make sure your memory block is not unmapped, swapped out *or somehow made inaccessible*.
The memory is always *accessible*, just perhaps not at this precise clock cycle, which is why you want to use locked memory in interrupts and likewise. Just strike the "somehow made inaccessible" bit. Any driver developers should be assumed to have some more knowledge, and the ones that don't are not helped by the explanation.
My suggestion:
I don't mean that the wiki needs to be a newbie manual, but one shouldn't give novice developers the room to make any false guesses.This function will make sure your memory block is not unmapped or swapped out. This is only useful during interrupts, device driver code or similar.
Furthermore, I do think there are some of us that don't exactly know what "page locking" means (especially since we can never lock or unlock *pages*, only memory, at least according to the name of the functions: Lock/UnlockMem).
This is how I understand it (I hope I'm conceptually correct, I haven't bothered with page size and stuff):
If we allocate and lock 16 Mbyte of memory, and then free it without unlocking, the system will get its 16 Mbyte back. However, the system cannot swap or move these 16 Mbyte. Nonetheless, these 16 Mbyte are available for any new allocations. Any 1 Mbyte allocations will eventually get a piece of these 16 Mbyte. But, now imagine the system running out of memory. The system tries to swap out memory, but the big 16 Mbyte chunk of memory cannot be swapped since it's locked, even though not all of the 16 Mbyte of it are used.
Did I get it right?
I think I made some misplaced quotes in the beginning of the thread which lead some to believe that locked memory can't be freed -- which it can.
Furthermore, I also think nbache's change suggestion is good.
Re: Memory allocation
I woul suggest replacing "somehow" with "otherwise". Then it would read:jaokim wrote:I'm still not very comfortable with this "definition":This is not a definition. I would call "somehow" a random event, which a computer system really can't do.This function will make sure your memory block is not unmapped, swapped out *or somehow made inaccessible*.
That seems clearer to me, and still achieves the intended goal (which removing it entirely does not).This function will make sure your memory block is not unmapped, swapped out *or otherwise made inaccessible*.