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. FastMM4 combines all the features of FastMM2 and FastMM3 (and some nice new ones) and will obsolete both older versions when it is released. FastMM4 is faster, uses less memory, it catches attempts to free most invalid pointers, now it's supporting 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, enriched with Enhanced MM sharing options between application and DLLs (Refer to the "Usage" section inside the source file for details on how to enable this).
FastMM version 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. Delphi 7 loads about 10% faster and is noticeably more responsive if this replacement DLL is copied 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 Delphi 2005 and newer versions you'll need to patch Delphi 2005 to accomodate memory manager replacement.FastMM 4.10 adds a new "FullDebugMode" option. What this does are: Add a header and footer to all blocks to catch buffer overruns; 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; Zeroes out all freed memory, so using freed blocks should lead to errors being raised closer to the cause of the problem; Reports attempts to call virtual methods of freed objects (provided the blocks have not already been reused).
In "FullDebugMode" freed blocks are never combined with adjacent free blocks and are never returned to the operating system (so once a block of a certain size has been allocated, that block will exist for the duration of the process). They may be reused however. Factor in the extra processing required to do the stack traces and the memory used to store them and you will rightfully conclude that "FullDebugMode" is slow, uses a lot of memory and tends to fragment badly. It is intended for debugging only!
Errors can now also be logged to a text file through the "LogErrorsToFile" option.
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.Read updates of FastMM through
FastMM News Feed (will open in new window), or download FastMM from SourceForge.
Attempts to support both Linux and Windows for cross-platform development were made, and a cross-platform version of the VCL known as CLX shipped in 2002 with the release of Delphi 6. The CLX technology effort has faded, and with the failure of Kylix, the CLX was abandoned too.
Delphi 7, released in August 2002, became the standard version used by more Delphi developers than any other single version, and remains still actively used to this date.
Delphi 8, released December 2003, was a .NET-only release that allowed developers to compile Delphi Object Pascal code into .NET CIL.
By Ferdinand Liu