FastMM.. any work in progress?
Clément Doss
FastMM really rocks. I just can't build a project without it anymore.
I just checked for an upgrade, but instead I read a rather old post suggesting some
changes for a FastMM5 incarnation. I'm just wondering if there's any work in progress
for this revolutionary MM.
Cheers,
Clément
Pierre le Riche
> FastMM really rocks. I just can't build a project without it anymore.
Thanks :-)
> I just checked for an upgrade, but instead I read a rather old post
> suggesting some changes for a FastMM5 incarnation. I'm just wondering if
> there's any work in progress for this revolutionary MM.
I have a new version almost ready. I'm planning to release it soon after
Tiburon ships, to allow me some time to ensure that it is compatible
with Tiburon as well.
Regards,
Pierre
Tommi Prami
> Tiburon ships, to allow me some time to ensure that it is compatible
Way Cool !!!
Tommi Prami
FastMM is clearly in Top 3 of things that have happened in/with/for
Delphi in many years.
All I would like to see have same functionality as memchk.pas (and
EurekaLog should have, but I actually didn't get it to work, so we did
not purchase it, reported it to them, but never received any answer on
it) has (For older Delphi), to put IDE into the line where memory was
allocated. To make Finding the memleaks magnitude easier. This could
only be supported for D2007+ (or something, no need to support every
single Delphi out there)
.
-TP-
Sanyin
"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:486be0ba$1...@newsgroups.borland.com...
Whats new in v5?
Clément Doss
>
> I have a new version almost ready.
I'm planning to release it soon after
> Tiburon ships, to allow me some time to ensure that it is compatible
> with Tiburon as well.
This week is getting better by the minute! :D
Pierre le Riche
> Whats new in v5?
Sorry, I may have given the wrong impression. It's not V5, since most of
the internals are the same. However, I have added several features over
the past year, and I have also received many community contributions
that I will be including in the release.
Here's what I have so far (excuse the formatting, it is a copy-and-paste
from the source):
- Added the Romanian translation. (Thanks to Ionut Muntean.)
- Optimized the GetMemoryMap procedure to improve speed.
- Added the GetMemoryManagerUsageSummary function that returns a
summary of
the GetMemoryManagerState call. (Thanks to Hallvard Vassbotn.)
- Added the French translation. (Thanks to Florent Ouchet.)
- Added the "AlwaysAllocateTopDown" FullDebugMode option to help with
catching bad pointer arithmetic code in an address space > 2GB.
This option
is enabled by default.
- Added the "InstallOnlyIfRunningInIDE" option. Enable this option to
only install FastMM as the memory manager when the application is run
inside the Delphi IDE. This is useful when you want to deploy the
same EXE
that you use for testing, but only want the debugging features
active on
development machines. When this option is enabled and the
application is
not being run inside the IDE, then the default Delphi memory
manager will
be used (which, since Delphi 2006, is FastMM without
FullDebugMode.) This
option is off by default.
- Added the "FullDebugModeInIDE" option. This is a convenient
shorthand for
enabling FullDebugMode, InstallOnlyIfRunningInIDE and
LoadDebugDLLDynamically. This causes FastMM to be used in FullDebugMode
when the application is being debugged on development machines, and the
default memory manager when the same executable is deployed. This
allows
the debugging and deployment of an application without having to
compile
separate executables. This option is off by default.
- Added a ScanMemoryPoolForCorruptions procedure that checks the entire
memory pool for corruptions and raises an exception if one is
found. It can
be called at any time, but is only available in FullDebugMode.
(Thanks to
Marcus Mönnig.)
- Added a global variable
"FullDebugModeScanMemoryPoolBeforeEveryOperation".
When this variable is set to true and FullDebugMode is enabled,
then the
entire memory pool is checked for consistency before every GetMem,
FreeMem
and ReallocMem operation. An "Out of Memory" error is raised if a
corruption is found (and this variable is set to false to prevent
recursive
errors). This obviously incurs a massive performance hit, so enable
it only
when hunting for elusive memory corruption bugs. (Thanks to Marcus
Mönnig.)
- Fixed a bug in AllocMem that caused the FPU stack to be shifted by one
position.
- Changed the default for option "EnableMMX" to false, since using
MMX may
cause unexpected behaviour in code that passes parameters on the
FPU stack
(like some "compiler magic" routines, e.g. VarFromReal).
- Removed the "EnableSharingWithDefaultMM" option. This is now the
default
behaviour and cannot be disabled. (FastMM will always try to share
memory
managers between itself and the default memory manager when memory
manager
sharing is enabled.)
- Introduced a new memory manager sharing mechanism based on memory
mapped
files. This solves compatibility issues with console and service
applications. This sharing mechanism currently runs in parallel
with the
old mechanism, but the old mechanism can be disabled by undefining
"EnableBackwardCompatibleMMSharing" in FastMM4Options.inc.
- Fixed the recursive call error when the EnableMemoryLeakReporting
option
is disabled and an attempt is made to register a memory leak under
Delphi
2006 or later. (Thanks to Thomas Schulz.)
- Added a global variable "SuppressMessageBoxes" to enable or disable
messageboxes at runtime. (Thanks to Craig Peterson.)
- Added the leak reporting code for C++ Builder, as well as various other
C++ Builder bits written by JiYuan Xie. (Thank you!)
- Added the new Usage Tracker written by Hanspeter Widmer. (Thank you!)
Regards,
Pierre
Sanyin
>
>> Whats new in v5?
>
> - Changed the default for option "EnableMMX" to false, since using
Can you explain this behaviour?It is not safe to use MMX?
Pierre le Riche
> Can you explain this behaviour?It is not safe to use MMX?
It is safe to use MMX, just not in the memory manager. :-) Some of the
"compiler magic" functions pass a floating point parameter on the FPU
stack. If such a routine calls the memory manager and the memory manager
uses MMX then that FPU parameter will be destroyed, since you cannot use
the FPU and MMX at the same time.
So far I have only seen this happen in custom variant code, so
admittedly it is rare for this to happen. However, the gain from using
MMX is very small (less than 2%), so I decided to play it safe and
switch it off by default.
Regards,
Pierre