🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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?
#280
Author: Clément Doss
Date: Wed, 02 Jul 2008 14:03
11 lines
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?
#285
Author: Pierre le Riche
Date: Wed, 02 Jul 2008 20:10
16 lines
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?
#287
Author: Tommi Prami
Date: Thu, 03 Jul 2008 06:17
4 lines
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?
#288
Author: Tommi Prami
Date: Thu, 03 Jul 2008 06:24
15 lines
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?
#289
Author: Sanyin
Date: Thu, 03 Jul 2008 13:29
18 lines
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?
#291
Author: Clément Doss
Date: Thu, 03 Jul 2008 14:59
9 lines
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?
#297
Author: Pierre le Riche
Date: Sat, 05 Jul 2008 08:38
97 lines
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?
#228
Author: Sanyin
Date: Mon, 14 Jul 2008 07:13
10 lines
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?
#229
Author: Pierre le Riche
Date: Mon, 14 Jul 2008 08:15
17 lines
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