Heap defragmentieren

[N. B. (mastercpp)]

Hallo!

Ich benutze in meinen Projekten gerne mal dynamischen Speicher, da das 
in manchen Situationen einfach von Vorteil ist. Da bei zu häufigem 
Einsatz von malloc und free der Heap bekanntermaßen dazu neigt zu 
fragmentieren, habe ich eine auf Handles (void**) basierende 
Heap-Verwaltung geschrieben, die den Heap bei bedarf defragmentiert.
Dazu wird zunächst mit malloc ein großer Speicherblock allokiert. Dann 
können folgende Funktionen verwendet weren, die jeweils Handles als 
Argumente akzeptieren und/oder zurückgeben:
- alloc  (=malloc)
- ralloc (=realloc)
- ualloc (=free)
Das Ganze ist noch beta. D.h, es müssen noch eventuelle Bugs beseitigt 
werden, es müssen noch ein paar Checks auf ungültige Argumente eingebaut 
werden und es muss noch etwas optimiert werden.
Der Einsatz loht sich ab ca 2-4KB RAM, denn für jeden allozierten Block 
benötigt man 2*sizeof(void*) Bytes Overhead. Außerdem ist es nicht für 
zeitkritische Systeme geeignet, da man nicht vorhersagen kann, wie lange 
ein alloc/ralloc dauert.
Ich würde gerne Wissen was ihr generell von dieser Idee haltet. Außerdem 
wäre es nett wenn ihr eventuelle Bugs hier hin postet und/oder behebt. 
Optimierungsvorschläge sind natürlich auch gern gesehen, sofern sie 
nicht das ganze Konzept über Bord werfen.

Download: http://www.stud.uni-hannover.de/~nilschr/msp430/ (unten)

MfG

[Peter D. (peda)]

Nils Brause wrote:

> Ich benutze in meinen Projekten gerne mal dynamischen Speicher, da das
> in manchen Situationen einfach von Vorteil ist.

Kannst Du dafür mal ein konkretes Beispiel geben, wo das von Vorteil ist 
?

Ich komme eigentlich immer gut klar, wenn ich den Speicher direkt 
deklariere (z.B. am Anfang der Funktion).

In ner MC-Anwendung muß ja immer der Worst-case Speicher verfügbar sein, 
da ich ja z.B. auf der Waschmaschine nicht ausgeben kann "schließen sie 
andere Anwendungen und starten sie das Waschprogramm erneut" oder "nicht 
genügend Speicher, um Weichspüler einlaufen zu lassen".


Peter

[(Gast) (Gast)]

Peter Dannegger wrote:
> ..."schließen sie andere Anwendungen und starten sie das Waschprogramm
> erneut"

Sowas in der Art ist mir auch durch den Kopf gegangen:-) Speicherfresser 
wie FIFOs o.ä lege ich deswegen immer statisch an und den 
Wurst-Käse-Fall für Speicher von autom. Variablen kann ich abschätzen 
und schauen, ob mir dafür genug frei bleibt.

Für eine private Bastelei habe ich eine grafische Oberfläche mit 
Touchscreen. Primär steuert das Teil ne Radiokarte und Verstärker an. 
Sekundär kann das Teil noch ein paar Spielerchen im kooperativen 
Multitasking starten (Tetris, Eieruhr, ...). Die Hauptanwendung 
"Betriebssystem"/Radio muß natürlich seinen festen Speicher bekommen. 
Die nachträglich startbaren Gimmiks könnten aber von Nils 
Speicherverwaltung profitieren, da ich für diese nicht garantieren muß, 
daß für alle gleichzeitig genug RAM da ist. "Taschenrechner kann wegen 
Speicherauslastung nicht gestartet werden" wäre hier OK.

[Andreas S. (andreas) (Admin)]

Peter Dannegger wrote:
> In ner MC-Anwendung muß ja immer der Worst-case Speicher verfügbar sein,
> da ich ja z.B. auf der Waschmaschine nicht ausgeben kann "schließen sie
> andere Anwendungen und starten sie das Waschprogramm erneut" oder "nicht
> genügend Speicher, um Weichspüler einlaufen zu lassen".

Das Problem bei der Heap-Fragmentierung ist ja nicht dass zu wenig 
Speicher frei wäre, sondern dass der Speicher fragmentiert ist. Das 
passiert, wenn Speicherblöcke verschiedener Größe in unterschiedlicher 
Reihenfolge reserviert/freigegeben werden.

[Rene (Gast)]

Wie Peter vermeide ich auch dynamischen Speicher. Falls ich doch 
aufgrund der dynamishen Natur des Prozesses welchselnde Speicher haben 
muesste, wuerde ich mit Bufferpools arbeiten, es muesste aber immer 
bestimmt sein wieviel Speicher frei ist. Normalerweise ist alles bei 
powerup definiert. Der speicher, den eine Prozedur braucht ist auch 
abgezaehlt und definiert.

[Uhu U. (uhu)]

Ich finde auch, daß die Benutzung von dynamischem Speicher auf einem µC 
nicht sehr sinnvoll ist.

Es mag sein, daß es hier und da mal einen guten Grund gibt, darauf 
zurückzugreifen, die technisch gerechtigten Einsätze dafür sind ziemlich 
rar.

Die Probleme:
- Dynamischer Speicher ist nicht echtzeitfähig
- Selbst bei einem sonst korrekten Programm kann niemand garantieren,
  daß es nicht doch irgendwann wegen Problemen im Heap versagt.
- Es muß reichlich Speicher verfügbar sein
- Heapcorruptions sind wohl die am schwierigsten zu debuggenden Fehler.


Das sind Ausschlußkriterien für alle Anwendungen, die irgendwelche 
Maschinen steuern.