xenic wrote:If the memory is locked by default, shouldn't it be automatically unlocked by default when calling Freevec(). I say that for 2 reasons:
1. I collect all the OS4 sources I can obtain and found several programs that use AllocVecTags() without any UnLockMem() calls. To me that indicates that there may be a lot of OS4 programs for (which I don't have the sources) that are using AllocVecTags() without UnLockMem(). There is no way of knowing how much locked memory is accumulating on our systems.
2. One of the reasons behind the implementation of the original AllocVec() was automatic memory resource tracking (i.e. you don't need to track memory allocation sizes in your program). What sense does it make to have a memory allocation function ( AllocVecTags() ) that tracks memory allocation sizes and then require a program to track all the memory sizes in order to unlock the memory before freeing it??
Maybe I've overlooked something in this discussion or in the WIKI & autodocs but having a function that tracks allocation sizes automatically and reguiring programs to track the allocation sizes seems very counterintuitive.
Yes, it seems rather wrong to me too (unless I also overlooked something). And until this thread I had never heard of UnLockMem().
ssolie wrote:Yes it is a bit strange but that is the way the API is right now.
If this was a mistake in the API, then perhaps the API should be fixed? *IF* it is not possible to change the behaviour without breaking backwards-compatibility with those (few?) programs which did UnLockMem(), then perhaps it could be left the same for all existing (compiled) programs, but changed for any programs compiled with the next SDK release? (I imagine that Exec would have two Interfaces, with the second newer one having revised AllocVec() functions, and newly compiled executables would automatically use the newer interface. Voila!)
ChrisH wrote:
Yes, it seems rather wrong to me too (unless I also overlooked something). And until this thread I had never heard of UnLockMem().
I remember reading about LockMem()/UnlockMem() in the autodocs but didn't make the connection between LockMem and the AVT_Lock tag for AlloccVecTags(). Fixing the API now may be impossible. The LockMem() autodoc states that memory locking is a nested function (Each LockMem() needs an UnlockMem() ) and not a switch. If they throw an UnlockMem() into FreeVec() and an existing program unlocks in again (as the WIKI now instructs us to do) who knows what will happen with the memory lock status. They could, however, add a new unlocking function (UnlockMemVec() ) which would obtain the size from memory allocated with AllocVecTags() and eliminate the need to track the sizes of all memory allocations within a program. Another option might be a new memory freeing function to go along with AllocVecTags() (like ReleaseVec() ) that would take care of the memory unlocking automatically.
I would assume that if AllocVecTags() is locking memory for backward compatability, all the other common memory allocation functions like AllocMem() would be doing the same. In that case, all OS3 programs and most OS4 programs written up to this point in time are locking memory and our SWAP partitions are unlikely to ever see much use. I think Solie has done a good job of documenting system memory allocation in the WIKI, but some of the facts presented have left some (most?) of us a little stunned.
xenic wrote:I would assume that if AllocVecTags() is locking memory for backward compatability, all the other common memory allocation functions like AllocMem() would be doing the same. In that case, all OS3 programs and most OS4 programs written up to this point in time are locking memory and our SWAP partitions are unlikely to ever see much use.
Well if under OS4, an AllocVec(size, MEMF_SHARED) also locks the memory by default then we're surely in for trouble because I've never seen anywhere in any code anyone unlocking this memory.
trixie wrote:
Well if under OS4, an AllocVec(size, MEMF_SHARED) also locks the memory by default then we're surely in for trouble because I've never seen anywhere in any code anyone unlocking this memory.
True, and the requirement for an explicit UnLockMem() because the memory is locked by default implies that the memory will remain locked after it is freed. If that's the case then we will have less memory released back to the system than we did with the old OS3 memory allocation system and are more likely to run out of memory.
We can't change the past but I think we need a new set of memory allocation/deallocation functions that don't have an AVT_Lock tag and don't lock memory by default. That way, a programmer would explicitly lock the memory with LockMem() if needed and match every LockMem() with an UnlockMem(). It's more likely that programmers will remember to match locks & unlocks that match an unlock to an AVT_Lock tag in the memory allocation. I'm suggesting AllocMemVec() and FreeMemVec() but the names don't really matter.
xenic wrote:True, and the requirement for an explicit UnLockMem() because the memory is locked by default implies that the memory will remain locked after it is freed. If that's the case then we will have less memory released back to the system than we did with the old OS3 memory allocation system and are more likely to run out of memory.
"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."
I think you are confused about what locking pages means. Please review the wiki page again (from the top) and let me know if anything is unclear.
We have AVT_Lock to forbid locking when using AllocVecTags(), we have ASOPOOL_LockMem to forbid locking when using memory pools. But what about item pools? Something like ASOITEM_Lock(Mem) is yet missing. Or isn't this required at all?
True, and the requirement for an explicit UnLockMem() because the memory is locked by default implies that the memory will remain locked after it is freed. If that's the case then we will have less memory released back to the system than we did with the old OS3 memory allocation system and are more likely to run out of memory.
How is this statement lacking? It seems to me that it describes the situation correctly. It might be better to include the word "effectively", but that is splitting hairs:
...we will effectively have less memory released back to the system...
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.
