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.... read more
There was a bug that may cause an access violation inside the MoveX16L4 routine when reallocating a memory block under certain rare circumstances. Even if you have never encountered this bug, it is strongly recommended that you update to version 4.62 or later to prevent future trouble. It can only occur if the Align16Bytes option is disabled and the UseCustomVariableSizeMoveRoutines option is enabled. (Thanks to Jud Cole for tracking it down.)... read more
Today sees the release of version 4.29, which implements many of the requests I have received over the past month. There are still some outstanding requests which I will try to get to ASAP.
I have decided to create a separate "beta releases" package where I will always upload the latest version first. If I don't hear anything bad about if for a while I will bump the version number and move it into the official release package. I'm going to be using uneven version numbers for beta releases and even numbers for final versions, so it would be immediately obvious whether a version was thoroughly tested or not.... read more
Allen Bauer from Borland has released three unofficial patches that greatly improves the stability of the Delphi 2005 IDE with replacement memory managers (like FastMM). (One of these patches replaces the patch that used to be included with FastMM.)
From 4.13 onwards a new DLL is included in the package: FastMM_DebugInfo.dll. This DLL allows FastMM to display unit/line number debug information for stack traces in "FullDebugMode". This requires that debug information be available for the application and libraries. FastMM_DebugInfo.dll uses the JCL library, so either a map file, a .jdbg file or embedded JCL debug data must be available.
FastMM 4.10 adds a new "FullDebugMode" option.
What this does is:
a) Add a header and footer to all blocks to catch buffer overruns
b) Stores a call stack trace on allocate and free to allow you to investigate the cause of an error. Only return addresses are displayed at this stage - the display of procedure name and line number detail (when debug info is available) may be implemented at a later stage.
c) Zeroes out all freed memory, so using freed blocks should lead to errors being raised closer to the cause of the problem.
d) Reports attempts to call virtual methods of freed objects (provided the blocks have not already been reused).... read more
Included in the FastMM 4.09 archive is a patch fix for the bug affecting replacement borlndmm.dll files with Delphi 2005 (QC#14007). Compile the patch, close Delphi, and run it once to patch your vclide90.bpl. You will now be able to use the replacement borlndmm.dll to speed up the Delphi 2005 IDE as well. (This patch might also improve the IDE stability.)
FastMM 4.08 introduces a small .dpr project that allows you to build a replacement borlndmm.dll that you may use to replace the memory manager that the Delphi IDE uses. My Delphi 7 loads about 10% faster and is noticeably more responsive if I copy this replacement DLL over the DLL in the \Bin folder.
Unfortunately there appears to be a bug in Delphi 2005 that prevents this replacement DLL from working under Delphi 2005 (QC#14007), so for now this replacement is only for Delphi 7 and older versions.
Hot off the compiler. As always, comments and suggestions are welcome.
- Uses less memory
- Catches attempts to free most invalid pointers
- Added support for Delphi 5 and 6
- DLLs automatically free leaked memory when unloading
- Supports 3GB user address space under Windows 32-bit (with /3GB switch)*
- Supports 4GB user address space under Windows 64-bit*
- Enhanced MM sharing options between application and DLLs
*Refer to the "Usage" section inside the source file for details on how to enable this.
Today FastMM 3.03 and FastMM 2.07 were released. FastMM3 got a a few minor speed optimizations and a bug affecting DLLs was fixed in both: A DLL would erroneously check for memory leaks on shutdown, even when it was sharing the main application's memory manager.
FastMM4 is done and is currently being fine-tuned and tested internally. In the Fastcode memory manager challenge benchmarks it is currently 6.5% faster than FastMM3 while using less memory (benchmarked on an Athlon 63 3000+). FastMM4 combines all the features of FastMM2 and FastMM3 (and some nice new ones) and will obsolete both older versions when it is released.
FastMM 3.01 has been released today. It fixes a bug affecting Windows 9X.
This is the first public release. I am currently working on a new version which is even faster... more to come soon.