15 March 2024, 15:52 | #1 |
Registered User
Join Date: Nov 2019
Location: Celle / Germany
Posts: 147
|
free - but keep - memory pool
I created a memory pool using CreatePool().
I need to free the pool but keep it, as maybe there will be allocated memory in the pool again. Using DeletePool() will free the memory but destroy the pool as well. Is there any way to free the pool, but keep it? |
15 March 2024, 16:08 | #2 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,223
|
FreePooled is what you are looking for.
|
15 March 2024, 16:43 | #3 |
Registered User
Join Date: Nov 2019
Location: Celle / Germany
Posts: 147
|
Unfortunately not: FreePooled() needs address an size of *each* memory block that belongs to the pool, and I dont store these data.
If I have to manage a memory list to keep track of all the memory snippets I allocated, I just could use good old AllocMem()/FreeMem() instead of the pooling. |
15 March 2024, 16:48 | #4 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,223
|
In that case, system pools are not what you are looking for. AllocMem() and custom code, as you proposed, are the solution.
|
16 March 2024, 12:18 | #5 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
Quote:
The memory pools are helpful if you are going to make many, many small allocations over the lifetime of your application. These small allocations will invariably contribute negatively to general memory fragmentation issues (the more fragments, and the more smaller fragments, the slower allocating and freeing memory will become). If you can stick them all into a memory pool instead, the problem practically goes away because any fragmentation, if at all, will only happen in the pool. Memory pools are also helpful if you need to make sure that every single memory allocation made is freed before your application eventually exits. The pools keep track, generally, of all the allocations made. No need to keep track of them individually all by yourself. Memory pools can be used to group together related allocations which you will be releasing together anyway in your application. Instead of allocating these one at a time, you create a pool for them, allocate the memory you need, make use of it, then free the pool. Finally, memory pools are a bit more efficient than making individual allocations through AllocMem/FreeMem/AllocVec/FreeVec. Each time you call one of these, the operating system briefly needs to stop multitasking until the function has completed its task. This kind of thing happens much more rarely if you call AllocPooled/FreePooled because a pool allocates the requested memory from one of the puddles which make up the pool. No need to call Forbid/Permit as part of the job all the time. If you can make them work for you, memory pools can make memory management much, much simpler. You certainly can make use of more than one pool in your application over time, disposing and re-creating them as necessary. |
|
16 March 2024, 13:05 | #6 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,378
|
A possibility is to call CreatePool right after DeletePool, to recreate the deleted pool.
|
16 March 2024, 14:11 | #7 |
Registered User
Join Date: Nov 2019
Location: Celle / Germany
Posts: 147
|
@meynaf: That is my workaround since yesterday!
@Olaf Barthel: Yes, for these reasons I want to use pools. While digging in the source code of a lib that handles linked lists in AmiBlitz, I found out that someone started to implement dynamic lists that allocate memory only if a list element is added. This way you can dim a list this way: Dim mylist.TagItem(0) This way that list is initiated and a pool is been created: the coder already used pooling for that purpose which seems to be the right solution. But the feature is not complete: every time a new list entry is created, the memory will be allocated from the pool, but the memory is never been freed, even after exiting the program. My problem is: the initiation of the dynamic array as well as the pool creation is done in another blitzlib (arrayslib). The list handling and memory allocation itself is done in linkedlistlib. To be able to clear a list at runtime, I have to free the pool in that lib. I already added a routine to delete and recreate a pool, if a list is been cleared. That works as expected but is not the best solution as I delete a pool that has been created from another lib. |
17 March 2024, 10:50 | #8 |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 538
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
A500 trapdoor memory: free design | PeteAU | Hardware mods | 637 | 05 May 2024 13:34 |
How to free memory | commodoresales | New to Emulation or Amiga scene | 11 | 16 March 2012 18:15 |
Thanks for the memory (SIMMS for free!) | Paul_s | MarketPlace | 1 | 05 October 2010 14:26 |
Deallocating RAM from the Memory Pool | Zetr0 | support.Hardware | 27 | 20 February 2009 11:49 |
Available free Memory on CDTV ? | astuermer | support.Hardware | 0 | 27 May 2005 22:22 |
|
|