BorlandTalk.com Forum Index BorlandTalk.com
Borland discussion newsgroups
 
Archives   FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

MemoryLeak reporting problem

 
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi Language BASM
View previous topic :: View next topic  
Author Message
Atle Smelvær
Guest





PostPosted: Thu Mar 16, 2006 4:03 pm    Post subject: MemoryLeak reporting problem Reply with quote



Here is a little test function of mine:

procedure TForm1.Button1Click(Sender: TObject);
type
TMyNewRec = record
i1,i2,i3,i4: integer;
end;
PMyNewRec = ^TMyNewRec;
var
i: integer;
i1,i2: int64;
rec: PMyNewRec;
mm: TMemoryHandler;
begin
ReportMemoryLeaksOnShutdown := true;
mm := TMemoryHandler.Create(16,2048,2048);
try
if QueryPerformanceCounter(i1) then
begin
for i := 0 to 1000000 do
mm.New;
QueryPerformanceCounter(i2);
Memo1.Lines.Add(Format('MemoryHandler: %d',[i2-i1]));
end;
finally
mm.Free;
end;
if QueryPerformanceCounter(i1) then
begin
for i := 0 to 1000000 do
New(rec);
QueryPerformanceCounter(i2);
Memo1.Lines.Add(Format('FastMM4: %d',[i2-i1]));
end;
end;

When I have ReportMemoryLeaksOnShutdown on, I get information about
TMemoryHandler leaking some memory (and that's not right). The last part
where I do New(rec); is the part where it is leaking memory (on purpose). If
I comment the loop with this "New(rec)", FastMM do not report any memory
leaks.

Is this something that's been corrected in a new version?

-Atle
Back to top
Atle Smelvær
Guest





PostPosted: Thu Mar 16, 2006 4:03 pm    Post subject: Re: MemoryLeak reporting problem Reply with quote



btw: here's the results I get:

MemoryHandler: 25524
FastMM4: 78167

This should maybe mean that there are still possibility for improvements on
FastMM4 allocation speed. I'll look more into why the difference is this big
when I get time for it.

And this MemoryHandler do take care of fragmentation etc. (if you wonder,
but maybe a simpler approach than FastMM).

-Atle
Back to top
Pierre le Riche
Guest





PostPosted: Fri Mar 17, 2006 4:03 pm    Post subject: Re: MemoryLeak reporting problem Reply with quote



Hi Atle,

Quote:
When I have ReportMemoryLeaksOnShutdown on, I get information about
TMemoryHandler leaking some memory (and that's not right). The last part
where I do New(rec); is the part where it is leaking memory (on purpose).
If I comment the loop with this "New(rec)", FastMM do not report any
memory leaks.

When you call "new" the memory block is not cleared or initialized, so one
of the blocks will still have the class pointer of the TMemoryHandler.
Consequently FastMM thinks that the leaked block is of the class
TMemoryHandler when it is not. Class detection of leaked blocks is not 100%
accurate.

Regards,
Pierre
Back to top
Pierre le Riche
Guest





PostPosted: Fri Mar 17, 2006 4:03 pm    Post subject: Re: MemoryLeak reporting problem Reply with quote

Quote:
This should maybe mean that there are still possibility for improvements
on FastMM4 allocation speed. I'll look more into why the difference is
this big when I get time for it.

You're not comparing apples to apples here. FastMM is a complete memory
manager, while it looks like TMemoryHandler sits on top of the MM and just
splits off equal sized blocks from a pre-allocated pool. FastMM has to be
thread safe, and it has to cater for all possible block sizes while still
having a reasonable memory footprint.

Regards,
Pierre
Back to top
Atle Smelvær
Guest





PostPosted: Mon Mar 20, 2006 9:03 am    Post subject: Re: MemoryLeak reporting problem Reply with quote

Quote:
When you call "new" the memory block is not cleared or initialized, so one
of the blocks will still have the class pointer of the TMemoryHandler.
Consequently FastMM thinks that the leaked block is of the class
TMemoryHandler when it is not. Class detection of leaked blocks is not
100% accurate.

Thanks for your answer. Is there any constants that I can change to make
FastMM (D2006 version) initialize the memory when creating it?

-Atle
Back to top
Atle Smelvær
Guest





PostPosted: Mon Mar 20, 2006 10:03 am    Post subject: Re: MemoryLeak reporting problem Reply with quote

Quote:
You're not comparing apples to apples here. FastMM is a complete memory
manager, while it looks like TMemoryHandler sits on top of the MM and just
splits off equal sized blocks from a pre-allocated pool. FastMM has to be
thread safe, and it has to cater for all possible block sizes while still
having a reasonable memory footprint.

I know that. But IsMultiThread is actually false. With IsMultiThread on I
get this:

MemoryHandler: 25402
FastMM4: 196133

And since FastMM is doing internal block pooling, I thought it would be more
close to this memory pool manager I use.

Anyway, I guess you have to mix sizes to get better speed on realloc.

One thing on my wishlist would be a memoryhandler that had two GetMem
styles. One for a mixed pool (where realloc would be faster), and one where
small sizes have their own pools.

All record, node and object creation will never use realloc, so these should
use the special sized pools. Strings, dynamic arrays, TList memory pointer,
TMemoryStream etc. should use the mixed pool.

Is it possible to do something like this?

Since Borland already integrated the memory manager, they should be able to
adjust object creation etc. to use the right allocator.

-Atle
Back to top
Pierre le Riche
Guest





PostPosted: Mon Mar 20, 2006 10:03 pm    Post subject: Re: MemoryLeak reporting problem Reply with quote

Hi Atle,

Quote:
I know that. But IsMultiThread is actually false. With IsMultiThread on I
get this:
MemoryHandler: 25402
FastMM4: 196133

Hmm, that is a big difference...

Quote:
And since FastMM is doing internal block pooling, I thought it would be
more close to this memory pool manager I use.

So do I. I can't really explain it without having seen your implementation.
FastMM is optimized to handle the allocation and freeing of small blocks
very efficiently, so this is an intriguing result.

Quote:
One thing on my wishlist would be a memoryhandler that had two GetMem
styles. One for a mixed pool (where realloc would be faster), and one
where small sizes have their own pools.

That's an interesting idea. It would certainly open up some opportunities
for speed/fragmentation improvements.

Quote:
Is it possible to do something like this?

I'm sure it would be, but it would require a couple of changes to the RTL
interface. Perhaps a new GetFixedMem call or something like that for memory
blocks that should not be resized.

Regards,
Pierre
Back to top
Pierre le Riche
Guest





PostPosted: Mon Mar 20, 2006 10:03 pm    Post subject: Re: MemoryLeak reporting problem Reply with quote

Hi Atle,

Quote:
Thanks for your answer. Is there any constants that I can change to make
FastMM (D2006 version) initialize the memory when creating it?

Unfortunately not. The closest is to use AllocMem (which zeroes out memory)
instead of GetMem, but it does come with a performance penalty of course. In
FullDebugMode FastMM clears all freed memory to track memory overwrite bugs.

Regards,
Pierre
Back to top
Display posts from previous:   
Post new topic   Reply to topic    BorlandTalk.com Forum Index -> Delphi Language BASM All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2006 phpBB Group
SEO toolkit © 2004-2006 webmedic.