-
pierre_le_riche committed revision 5 to the FastMM SVN repository, changing 1 files.
2009-11-09 22:56:39 UTC by pierre_le_riche
-
pierre_le_riche committed revision 4 to the FastMM SVN repository, changing 2 files.
2009-11-05 20:31:03 UTC by pierre_le_riche
-
pierre_le_riche committed revision 3 to the FastMM SVN repository, changing 3 files.
2009-09-22 13:25:07 UTC by pierre_le_riche
-
1. Use additional thread index slot to assign its own memory pool
2. Always create memory from its own pool
3. When release memory, if it is not found in its own pool, search global pool list to release it. To minimized the search, use the few low order bit to identify it pool/pool group.
2009-09-16 16:58:38 UTC by nobody
-
pierre_le_riche changed the public information on the FastMM project.
2009-09-11 10:30:13 UTC by pierre_le_riche
-
pierre_le_riche made 1 file-release changes.
2009-08-28 11:06:01 UTC by pierre_le_riche
-
pierre_le_riche made 2 file-release changes.
2009-08-28 11:05:01 UTC by pierre_le_riche
-
pierre_le_riche committed revision 2 to the FastMM SVN repository, changing 1 files.
2009-08-28 10:53:29 UTC by pierre_le_riche
-
Thanks for the reply.
We have programs written by a variety of programmers over the years (some no longer around) so we have a mixture of coding styles. Some used GetMem() others New(), some made sure the memory block was in a known state after the allocation, some did not. All the programs and methods worked using the older Delphi memory manager. Just in some cases due to sheer luck, I...
2009-08-21 18:04:36 UTC by equinoxis
-
If FastMM raises an exception (other than EOutOfMemory) then it means that the memory pool is corrupted and pretty much "all bets are off". Attempting any kind of recovery after that would be pointless. At that point the safest thing would be for the application to hang, otherwise you risk corrupting data further. (The memory pool is shared across threads, so if one thread corrupts the...
2009-08-19 21:39:12 UTC by pierre_le_riche
