Thread View: borland.public.delphi.language.basm
9 messages
9 total messages
Started by Clément Doss
Wed, 02 Jul 2008 14:03
FastMM.. any work in progress?
Author: Clément Doss
Date: Wed, 02 Jul 2008 14:03
Date: Wed, 02 Jul 2008 14:03
11 lines
1178 bytes
1178 bytes
Hi, 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
Re: FastMM.. any work in progress?
Author: Pierre le Riche
Date: Wed, 02 Jul 2008 20:10
Date: Wed, 02 Jul 2008 20:10
16 lines
1396 bytes
1396 bytes
Hi Cl�ment, > 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
Re: FastMM.. any work in progress?
Author: Tommi Prami
Date: Thu, 03 Jul 2008 06:17
Date: Thu, 03 Jul 2008 06:17
4 lines
1177 bytes
1177 bytes
> 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 Way Cool !!!
Re: FastMM.. any work in progress?
Author: Tommi Prami
Date: Thu, 03 Jul 2008 06:24
Date: Thu, 03 Jul 2008 06:24
15 lines
1529 bytes
1529 bytes
> FastMM really rocks. I just can't build a project without it anymore. 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-
Re: FastMM.. any work in progress?
Author: Sanyin
Date: Thu, 03 Jul 2008 13:29
Date: Thu, 03 Jul 2008 13:29
18 lines
1522 bytes
1522 bytes
"Pierre le Riche" <pleriche@hotmail.com> wrote in message news:486be0ba$1@newsgroups.borland.com... > Hi Cl�ment, > >> 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. Whats new in v5?
Re: FastMM.. any work in progress?
Author: Clément Doss
Date: Thu, 03 Jul 2008 14:59
Date: Thu, 03 Jul 2008 14:59
9 lines
1191 bytes
1191 bytes
> > 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
Re: FastMM.. any work in progress?
Author: Pierre le Riche
Date: Sat, 05 Jul 2008 08:38
Date: Sat, 05 Jul 2008 08:38
97 lines
5345 bytes
5345 bytes
> 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
Re: FastMM.. any work in progress?
Author: Sanyin
Date: Mon, 14 Jul 2008 07:13
Date: Mon, 14 Jul 2008 07:13
10 lines
1271 bytes
1271 bytes
"Pierre le Riche" <pleriche@hotmail.com> wrote in message news:486f331e$1@newsgroups.borland.com... > >> Whats new in v5? > > - Changed the default for option "EnableMMX" to false, since using MMX may.... Can you explain this behaviour?It is not safe to use MMX?
Re: FastMM.. any work in progress?
Author: Pierre le Riche
Date: Mon, 14 Jul 2008 08:15
Date: Mon, 14 Jul 2008 08:15
17 lines
1682 bytes
1682 bytes
Hi Sanyin, > 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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads