ANN: FastMM 4.40 released (replacement memory manager for Delphi IDE and applications, free and open source)

[Pierre le Riche]

Hi All,

I've just uploaded the latest version to SourceForge. Here is some info
about FastMM:

Description:
A fast replacement memory manager for Borland Delphi Win32 applications
that
scales well under multi-threaded usage, is not prone to memory
fragmentation,
and supports shared memory without the use of external .DLL files.

Homepage:
http://fastmm.sourceforge.net

Advantages:
- Fast
- Low overhead. FastMM is designed for an average of 5% and maximum of 10%
overhead per block.
- Supports up to 3GB of user mode address space under Windows 32-bit and
4GB
under Windows 64-bit. Add the "$SetPEFlags $20" option (in curly braces)
to your .dpr to enable this.
- Highly aligned memory blocks. Can be configured for either 8-byte or
16-byte
alignment.
- Good scaling under multi-threaded applications
- Intelligent reallocations. Avoids slow memory move operations through
not performing unneccesary downsizes and by having a minimum percentage
block size growth factor when an in-place block upsize is not possible.
- Resistant to address space fragmentation
- No external DLL required when sharing memory between the application and
external libraries (provided both use this memory manager)
- Optionally reports memory leaks on program shutdown. (This check can be
set
to be performed only if Delphi is currently running on the machine, so
end
users won't be bothered by the error message.)
- Supports Delphi 5 (or later), C++ Builder 6 (or later), Kylix 3.

Change log:
Version 4.29 (30 September 2005):
- Added the "RequireDebuggerPresenceForLeakReporting" option to only
display
the leak report if the application is run inside the IDE. (Thanks to
Günther
Schoch.)
- Added the "ForceMMX" option, which when disabled will check the CPU for
MMX compatibility before using MMX. (Thanks to Jan Schlüter.)
- Added the module name to the title of error dialogs to more easily
identify
which application caused the error. (Thanks to Kristofer Skaug.)
- Added an ASCII dump to the "FullDebugMode" memory dumps. (Thanks to
Hallvard
Vassbotn.)
- Added the option "HideExpectedLeaksRegisteredByPointer" to suppress the
display and logging of expected memory leaks that were registered by
pointer.
(Thanks to Dan Miser.) Leaks registered by size or class are often
ambiguous,
so these expected leaks are always logged to file (in FullDebugMode) and
are
never hidden from the leak display (only displayed if there is at least
one
unexpected leak).
- Added a procedure "GetRegisteredMemoryLeaks" to return a list of all
registered memory leaks. (Thanks to Dan Miser.)
- Added the "RawStackTraces" option to perform "raw" stack traces, negating
the need for stack frames. This will usually result in more complete
stack
traces in FullDebugMode error reports, but it is significantly slower.
(Thanks to Hallvard Vassbotn, Dan Miser and the JCL team.)
Version 4.31 (2 October 2005):
- Fixed the crash bug when both "RawStackTraces" and "FullDebugMode" were
enabled. (Thanks to Dan Miser and Mark Edington.)
Version 4.33 (6 October 2005):
- Added a header corruption check to all memory blocks that are identified
as
leaks in FullDebugMode. This allows better differentiation between memory
pool corruption bugs and actual memory leaks.
- Fixed the stack overflow bug when using "RawStackTraces".
Version 4.35 (6 October 2005):
- Fixed a compilation error when the "NoMessageBoxes" option is set.
(Thanks
to Paul Ishenin.)
- Before performing a "raw" stack trace, FastMM now checks whether
exception
handling is in place. If exception handling is not in place FastMM falls
back to stack frame tracing. (Exception handling is required to handle
the
possible A/Vs when reading invalid call addresses. Exception handling is
usually always available except when SysUtils hasn't been initialized yet
or
after SysUtils has been finalized.)
Version 4.37 (8 October 2005):
- Fixed the missing call stack trace entry issue when dynamically loading
DLLs.
(Thanks to Paul Ishenin.)
Version 4.39 (12 October 2005):
- Restored the performance with "RawStackTraces" enabled back to the level
it
was in 4.35.
- Fixed the stack overflow error when using "RawStackTraces" that I thought
I
had fixed in 4.31, but unfortunately didn't. (Thanks to Craig Peterson.)
Version 4.40 (13 October 2005):
- Improved "RawStackTraces" to have less incorrect extra entries. (Thanks
to
Craig Peterson.)
- Added the Russian (by Paul Ishenin) and Afrikaans translations of
FastMM4Messages.pas.

Regards,
Pierre

[Liz]

Pierre le Riche wrote:

> I've just uploaded the latest version to SourceForge. Here is some
> info about FastMM:

Cool. Have to say FastMM is a cracking bit of work. I was scared to add
it to my d5 app.. now Im wishing I hda done it sooner!

--
Liz the Brit

[Cristian Nicola]

Would it be possible / viable for FastMM to implement somehow the internals
for GetHeapStatus ?

It would be really nice to monitor the memory usage from inside the
application, altough i don't know how much of a popular alternative would
that be.

Thank you very much for all the great work,

Kind regards,
Cristian Nicola

"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:434f...@newsgroups.borland.com...

[Cristian Nicola]

CatchUseOfFreedInterfaces directive would break the compile due to
LErrorMessageTitle being undefined...

Cristian Nicola

[Pierre le Riche]

Hi Cristian,

> CatchUseOfFreedInterfaces directive would break the compile due to
> LErrorMessageTitle being undefined...

Thanks. It will be fixed in the next version.

Regards,
Pierre

[Pierre le Riche]

Hi Cristian,

> Would it be possible / viable for FastMM to implement somehow the
> internals
> for GetHeapStatus ?
> It would be really nice to monitor the memory usage from inside the
> application, altough i don't know how much of a popular alternative would
> that be.

FastMM has two functions for this purpose: GetMemoryManagerState and
GetMemoryMap. FastMM differs too much from the current RTL memory manager to
make a GetHeapStatus compatible function practical.

Regards,
Pierre

[Cristian Nicola]

I'm very much aware of the differences and i know about the 2 functions
(altough i havent had time to play with them). I for one wouldnt mind if
GetMemoryManagerState would return a THeapStatus even with partial fields
filled.

I'll have a look later on tonight maybe i can put something up..

Cristian Nicola

"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:434f...@newsgroups.borland.com...

> FastMM has two functions for this purpose: GetMemoryManagerState and

[Liz]

Pierre le Riche wrote:

> I've just uploaded the latest version to SourceForge. Here is some
> info about FastMM:

Im struggling with one leak its reporting in a TCriticalSection I cant
seem to find out where or what is causing it.

--
Liz the Brit

[Leonel]

Liz wrote:

> Im struggling with one leak its reporting in a TCriticalSection I cant
> seem to find out where or what is causing it.

Hint: Build with debug DCUs, put a breakpoint on
TCriticalSection.Create and watch the call stacks.

Alternatively, look at IdComponent.pas in the initialization section.

--
Leonel

[Pierre le Riche]

Hi Liz,

> Im struggling with one leak its reporting in a TCriticalSection I cant
> seem to find out where or what is causing it.

It's probably the (in)famous Indy leak. It was discussed recently in the
BASM group. If you do a Google Groups search for Indy and TCriticalSection
I'm sure you'll find it.

Regards,
Pierre

[Liz]

Leonel wrote:

> Hint: Build with debug DCUs, put a breakpoint on
> TCriticalSection.Create and watch the call stacks.
>
> Alternatively, look at IdComponent.pas in the initialization section.

Hehe, seems I slept through the indy leak find :) Thank you

--
Liz the Brit

[Liz]

Pierre le Riche wrote:

> It's probably the (in)famous Indy leak. It was discussed recently in
> the BASM group. If you do a Google Groups search for Indy and
> TCriticalSection I'm sure you'll find it.

THanks

--
Liz the Brit

[Erick Sasse]

When I compile the BorlndMM.dll for performance, which defines I need
to change?

I have just compiled one with D7 and noticed that the DLL is extremmely
bigger (390K) than the precompiled one (26K).

What am I doing wrong? :)

I just want better performance in the IDE, not memory leak reports.

Thanks.

--
Erick Sasse
Brazil

[Pierre le Riche]

Hi Erick,

> When I compile the BorlndMM.dll for performance, which defines I need
> to change?

At the bottom of FastMM4Options.inc there are three defines that you can set
to pick which DLL you want to build. Settings these three defines will
automatically set all the others correctly.

> I have just compiled one with D7 and noticed that the DLL is extremmely
> bigger (390K) than the precompiled one (26K).
> What am I doing wrong? :)

You probably have TD32 debug info enabled in compiler options. Either that
or you're perhaps adding JCL debug info.

> I just want better performance in the IDE, not memory leak reports.

There is a precompiled one for the IDE in a subfolder.

Regards,
Pierre

[Erick Sasse]

Pierre le Riche wrote:

> There is a precompiled one for the IDE in a subfolder.

Can I just use this one instead of build my own?

--
Erick Sasse
Brazil

[Liz]

Erick Sasse wrote:

> Can I just use this one instead of build my own?

I did :) for both D5 and 2005!

--
Liz the Brit

[Max]

> - Supports up to 3GB of user mode address space under Windows 32-bit
and 4GB under Windows 64-bit. Add the "$SetPEFlags $20" option (in curly
braces) to your .dpr to enable this.

Is this option without negative effects on Win32 apps running on Win32 ?

[Liz]

Billy wrote:

> Does FastMM use Borlandmm.dll?

You replace it with the fastmm one.

--
Liz the Brit

[Billy]

Does FastMM use Borlandmm.dll?

[Pierre le Riche]

Hi Max,

Yes, all it does is it sets a flag in the EXE header that tells Windows that
the application can handle an address space larger than 2GB. If Windows
cannot give it more than 2GB, then the switch is just ignored. If, however,
you're running Windows x64 Edition you will get a 4GB address space. Without
this switch you'll always get 2GB no matter what version of Windows you run
it on.

There shouldn't be any performance impact when using this switch. There is
no difference between FastMM running in 2GB mode vs. 4GB mode - the code is
exactly the same. It is up to Windows to provide a bigger address space or
not... FastMM will use whatever is available.

Regards,
Pierre

[Pierre le Riche]

Hi Erick,

>> There is a precompiled one for the IDE in a subfolder.
> Can I just use this one instead of build my own?

Yes, I precompiled it with the correct options to save you the trouble.

Regards,
Pierre

[Pierre le Riche]

Hi Billy,

> Does FastMM use Borlandmm.dll?

As Liz said: You can replace the borlndmm.dll that came with Delphi with an
appropriate one from the FastMM archive. In most cases it will make whatever
you use it with a bit faster.

Regards,
Pierre

[Erick Sasse]

Pierre le Riche wrote:

> Yes, I precompiled it with the correct options to save you the
> trouble.

Thanks Pierre! You got my vote for Spirit of Delphi 2005! ;)

--
Erick Sasse
Brazil

[Shane Stump]

Is this library compatible with NexusDB? Or does NexusDB automatically use
its own MM?

Regards,

Shane

"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:434f...@newsgroups.borland.com...

[Jed Nicolau Filho]

Hi Pierre

Can FastMM avoid memory leak in a multi-thread application that has it ?

Thanks in advance

Best Regards

Jed

"Pierre le Riche" <pler...@hotmail.com> escreveu na mensagem
news:4350...@newsgroups.borland.com...

[Pierre le Riche]

Hi Jed,

> Can FastMM avoid memory leak in a multi-thread application that has it ?

FastMM is fully compatible with single- and multithreaded applications. If
the application has a memory leak, FastMM will pick it up.

Regards,
Pierre

[Pierre le Riche]

Hi Shane,

> Is this library compatible with NexusDB? Or does NexusDB automatically use
> its own MM?

To be honest, I don't know. I suspect that NexusDB may have some
dependencies on some of the extended functionality of their own NexusMM. I
think the best people to ask that question to would be the NexusDB folks
themselves.

Regards,
Pierre

[Jason]

Nexus DB internally uses their MM (NexusMM).

"Shane Stump" <ShaneStu...@StumpWare.com> wrote in message
news:4351...@newsgroups.borland.com...

[John le Roux]

Pierre

Baie goeie sagteware.

Groete

John le Roux

[Jed Nicolau Filho]

Thanks Pierre

Great.

Best Regards

Jed

"Pierre le Riche" <pler...@hotmail.com> escreveu na mensagem

news:4351...@newsgroups.borland.com...

[Jed Nicolau Filho]

Hi Pierre

How can I see when FastMM pick up a memory leak in
a multithreaded application ?

Thanks in advance

Best Regards

Jed

"Pierre le Riche" <pler...@hotmail.com> escreveu na mensagem

news:4351...@newsgroups.borland.com...

[Pierre le Riche]

Hi Jed,

> How can I see when FastMM pick up a memory leak in
> a multithreaded application ?

Just make sure that the "EnableMemoryLeakReporting" option is enabled in
FastMM4Options.inc. When your application shuts down all the memory leaks
will be listed, or written to log file (or both) depending on the options
you have selected.

Regards,
Pierre

[Pierre le Riche]

> Baie goeie sagteware.

Dankie :-)

[Jonathan Neve[Microtec]]

Pierre le Riche wrote:

> (Thanks to G|nther Schoch.)

> - Added the "ForceMMX" option, which when disabled will check the CPU

> for MMX compatibility before using MMX. (Thanks to Jan Schl|ter.)

FastMM looks very good. Is there any chance it might support BCB 5 some
time in the future?

--
Best regards,
Jonathan Neve
_______________
CopyTiger - advanced database replicator for Interbase/Firebird!
Web : http://www.microtec.fr/copycat/ct
_______________________________________
CopyCat - database replication components for Delphi/C++Builder!
Web : http://www.microtec.fr/copycat/cc

[Jed Nicolau Filho]

Thanks Pierre

Best Regards

Jed

"Pierre le Riche" <pler...@hotmail.com> escreveu na mensagem

news:4353...@newsgroups.borland.com...

[Pierre le Riche]

Hi Jonathan,

> FastMM looks very good. Is there any chance it might support BCB 5 some
> time in the future?

A gentleman by the name of Roddy Pratt sent me a list of changes required to
ensure BCB5 compatibility, but I forgot to implement them. I have just made
the necessary changes. The next version should work under BCB5.

Regards,
Pierre

[Jonathan Neve[Microtec]]

Pierre le Riche wrote:

That's good news, thanks a lot!

[Les block]

I have this problem...
LErrorMessageTitle is undeclared identifier when CatchUseOfFreedInterfaces
is set.
What am i doing wrong?

"Pierre le Riche" <pler...@hotmail.com> wrote in message
news:434f...@newsgroups.borland.com...

> Günther

> Schoch.)
> - Added the "ForceMMX" option, which when disabled will check the CPU for

> MMX compatibility before using MMX. (Thanks to Jan Schlüter.)

[Pierre le Riche]

Hi Les,

>I have this problem...
> LErrorMessageTitle is undeclared identifier when CatchUseOfFreedInterfaces
> is set.
> What am i doing wrong?

It was an oversight on my part. It fixed in 4.42.

Regards,
Pierre

[khariv]

>I have just compiled one with D7 and noticed that the DLL is extremmely
>bigger (390K) than the precompiled one (26K).
>
>What am I doing wrong? :)

I had this same problem - are you using some sort of memory-crash tracking
software? I was using EurekaLog in D7 and when I built the Borlndmm.dll,
it was huge. To fix this, disable your crash-catcher for this DLL. (In
Eureka, its under Options..EurekaLog.

--- posted by geoForum on http://delphi.newswhat.com