Re: GC performance - GC fragility
- From: Andre Kaufmann <andre.kaufmann_re_move_@xxxxxxxxxxx>
- Date: Sun, 27 Jan 2008 11:03:55 +0100
Micha Nelissen wrote:
Andre Kaufmann wrote:Also I don't think that the native heap has a much better cache
locality. Think of a native heap which has
1000 entries of the type:
[60 bytes free] [40 bytes allocated] [60 bytes free] [40 bytes.....]
{ it's called heap fragmentation }
What will happen if the applications now wants to allocate 80 bytes ?
Every entry has to be checked and touched. Not quite local (for this
example).
What a load of nonsense. Why must a heap have this kind of structure?
Well it's easy to call something nonsense.
And before we start to nitpick the heap sample should read:
>> [61 bytes free] [40 bytes allocated] [62 bytes free] [40 bytes.....]
Otherwise the heap implementation would be just too dumb.
I haven't tested FMM regarding heap fragmentation. But anyways it can't prevent it since this is what memory compaction of GC heaps tries to prevent.
Tell me what a heap will look like after the following loop (pseudo code).
loop i from 1..1000
pos1 = alloc 60 bytes
pos2 = alloc i + 1 bytes
free oldPos2
oldPos2 = pos2
You normally will end with a heap looking like a swiss cheese. AFAIK FastMM tries to fight this with granularity and passing different allocation sizes to different "heap blocks", but it can't be IMHO generally be prevented.
It's a big problem of long running applications.
It
doesn't. E.g. just read the top part of FastMM source code. Please try
to have at least a bit of clue about a subject before drawing any
conclusions on it.
You seem to have more clue than I have and since I haven't studied FastMM source code could you shed some light on the problem how a native heap can (generally) prevent fragmentation, without compacting the memory ?
Micha
Andre
.
- Follow-Ups:
- Re: GC performance - GC fragility
- From: Eric Grange
- Re: GC performance - GC fragility
- References:
- GC performance - GC fragility
- From: Eric Grange
- Re: GC performance - GC fragility
- From: Atmapuri
- Re: GC performance - GC fragility
- From: Andre Kaufmann
- Re: GC performance - GC fragility
- From: Micha Nelissen
- GC performance - GC fragility
- Prev by Date: Re: A Tale of Two Memory Managers (long)
- Next by Date: Re: Codegear-Please bring back C# ( for Delphi's sake )
- Previous by thread: Re: GC performance - GC fragility
- Next by thread: Re: GC performance - GC fragility
- Index(es):
Relevant Pages
|