FastMM 4.68

pierre_le_riche wrote:

"I have just uploaded FastMM 4.68. It contains a fix for a rare crash bug when the FulLDebugMode and RawStackTraces options are both enabled (thanks to Primoz Gabrijelcic for catching it).

There is also an enhancement that improves performance for 4+ CPU systems - the "NeverSleepOnThreadContention" option. (Thanks to Werner Bochtler and Markus Beth for their help with this.)

Currently the GetMem routine is very efficient at avoiding thread contention by switching to an alternate block handler when the requested block size is locked, but the FreeMem routine has no option but to wait if the block type to be freed is currently locked. The FreeMem routine puts the thread to sleep if it cannot free the block immediately, which works very well when the CPU has a lot of other work to do (i.e. the thread to CPU core ratio is high), but is not great when the CPU core would otherwise be idle. Unfortunately the sleep() call has a rather coarse granularity under Win32 and the thread may thus sleep longer than it needs to, wasting precious CPU cycles. This wastage is most apparent with quad CPU systems where the sleep() call has a higher probability of causing the CPU to go idle. In such cases it is better to put the CPU in a "busy waiting" loop so that it can continue the moment the block type is unlocked by another thread. This is what the "NeverSleepOnThreadContention" option does - but don't use it on anything less than a quad core CPU or performance nose dives.

Of course the best solution would be to avoid the thread contention completely. I am toying with the idea of adding the block to be freed to a "blocks to be freed" linked list in lock-free manner (if it cannot be freed immediately). It is then the responsibility of the next GetMem/FreeMem call to process this list and do the actual freeing. There are some issues to iron out, but this could solve this problem once and for all. The change is not a minor one, though, and this probably means FastMM5 is on the cards.

There are also some other feature requests than have been waiting in my inbox for quite a while: Better IDE integration (jump to the line in the source that caused the leak, etc.), better leak management (display a leak tree showing leak dependencies / related leaks instead of a simple list) and on-the-fly switching between debug and performance mode. There are many more, certainly enough to keep me busy for a long time to come!"