[Interest] memory fragmentation?

[Konrad Rosenbaum]

Hi,

On Tuesday 21 August 2012 12:01:49 Bo Thorsen wrote:
> Memory fragmentation is defined as the problem where you allocate a
> bigger chunk of memory than what is available, even if the total amount
> of free memory is available.
> 
> Do you know if the ^ implementation in .NET actually does the realloc
> stuff, or do they only say that it's a possibility? I ask because this
> sounds hard to do well. You either have a really slow operation running
> often (just moving stuff back) or an almost impossible task (move things
> *you will keep for a long time* to the front of temporary objects.

I'm not entirely certain how "C++" is implemented on .NET - it is an alien in 
that world, since it normally expects allocation that does not move around. My 
guess would be that it marks objects assigned to Type* style pointers as 
"unmovable".

See http://msdn.microsoft.com/en-us/library/ee787088.aspx for a detailed (and 
for MS untypically readable) description of the .NET Garbage Collector.

The short version:

.NET uses a generational and segmented garbage collector: small objects are 
created in an "ephemeral" memory area (large objects are presumed to be long-
lived from the start) and are marked "generation 0". When the GC discoveres 
that it promoted most of the objects to "generation 1" (not temporary anymore) 
or "generation 2" (long lived object) it marks the whole segment as 
"generation 2", which just makes the GC sweeps happen less often. A new 
segment is chosen as "ephemeral" then.

When the GC actually runs on a segment it does so in several phases. The 1st 
phase "mark" is: the GC checks which objects are there to stay and which ones 
can be removed (i.e. they do not have any connection to a running thread). 
Phase 2 is "sweep": it actually removes those objects. After that comes phase 
3 "compact": it reallocates objects to the start of their segment to eliminate 
fragmented space. If necessary it can even reallocate objects to other 
segments.

In other words: .NET manages memory in large chunks and automatically compacts 
those chunks when it feels this is necessary. So object references are 
pointers into a lookup table that contains the real memory location, which can 
change during GC runs.

> The one case where you might have a problem is if you do have
> allocs/deallocs done often (for example list views that change content
> often) and you sometimes alloc a big chunk of the memory in one go.

As far as I've seen in this discussion this falls into two categories:

1) Software on small and/or real-time systems that has critical parts and Qt 
as display. [I.e. physical memory is the limit.]

2) Software that crunches lots of data and is combined with a GUI - scientific 
applications, data analysis, etc. [I.e. pointer size is the main limit, memory 
can be extended for money]

> Things you can do to combat this is mostly to make your objects smaller.
> For example, use linked lists instead of arrays. The lists will add 4
> bytes to each object, but the the object sizes are much smaller.
> 
> If you want to go even further, you should add code to do memory
> intensive stuff on the disc - much much slower, but at least it will run.

Both solve the problem for category 2 software (data/number crunching with a 
GUI). I would in all earnesty add: go 64bit! Your target audience can easily 
use the added flexibility of 64bit pointers (some of them could use more if 
they could get it).

For category 1 (real time, small memory FP) I can only suggest: separate the 
processes. Have one that does the critical stuff in a deterministic manner 
with pre-allocated memory and another process for the display - if there is a 
memory problem in the display process it does not hurt much to just kill it, 
restart and resync with the main process. Yes, that is quite a bit of extra 
effort, but if you have serious worries about this it may be a lot easier than 
making something as complex as Qt predictable. (The one time I did program 
such a tool I even had the critical part in its own microcontroller.)


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120822/ebef8430/attachment.sig>