Fragen zur Speicherverwaltung an Insider

[Vi-P]

Ich habe schon gesucht und auch Google benutzt, Hinweise gefunden aber noch keine harten verlässlichen Aussagen insbs. auch im Hinblick auf zukünftige Versionen:
1. Wenn ich eine Map von einer Struktur habe und mir einen Pointer auf ein Element geben habe lassen, ist dieser Pointer auch noch sicher gültig, wenn zwischenzeitlich fleißig Lösch- und Einfügeoperationen getätigt wurden, vorausgesetzt (natürlich) das Element, auf das der Zeiger bezogen wurde, wurde nicht gelöscht.
2. Wie ist das bei einer Liste? Also auch wieder ein Zeiger auf ein Element. Die Liste wird fröhlich manipuliert. Das Element auf das der Zeiger referenziert aber nicht gelöscht wird.
3. Wie ist das bei einem String, der kräftig verlängert wurde.
4. Wenn man frisch und fröhlich mit Maps, Listen und Strings arbeitet, wird ja mit der Zeit der Speicher perforiert. Bei langer Laufzeit, kann das zum Problem werden. Man kann dann zwar das Programm neu starten und wieder von vorne beginnen. Bringt es was, die dynamischen Variablen alle zu löschen, wenn dies gerade ablauftechnisch möglich ist und dann wieder neu anzulegen, um sogenannte Speicherlecks durch Perforierung zu vermeiden.

Wäre hilfreich, zuverlässige Aussagen zu bekommen. Klar ist es möglich Kopien des jeweiligen Elements für einzelne Threads zu erstellen und danach zurück kopieren, schön und effizient ist das nicht, aber evtl. nötig. Und das gilt es (1-3) hier zu klären. Eine positive Aussage zu 4 würde ein Programm sparen, welches das eigentliche Programm wieder aufruft, nachdem sich dieses zum memory cleanup beendet hat.

[STARGÅTE]

1. Ja. Pointer zu Listenelementen und Mapelementen sind lebenslang (bezogen auf das Element) gültig.
   Auch wenn diese Elemente zB selbst weitere Listen oder Arrays haben die vergrößert oder verkleinert werden, bleibt das Element selbst immer an der selben Stelle im Speicher
2. Siehe 1.
3. Strings ändern ihre Adresse, weil es ein Zusammenhängender Speicherbereich ist/sein muss (was bei Listen und Maps nicht der fall sein muss). Jede Änderung kann ggf. zu einer neue String-Adresse führen. Abhilfe könnte hier ein Fix-String sein, der dann jedoch eine maximale Länge hat.
4. Dort habe ich keine genauen Informationen. Ja eine Liste wird mit der Zeit fragmentiert, wenn sehr viel Hinzufüg- und Löschoperationen durchgeführt werden. Ob PB selber defragmentiert weiß ich nicht. Von daher könnte es durchaus helfen, Listen ab und an komplett neu anzulegen (wenn man damit leben kann, dass die Elemente ihre Adresse wechseln; ansonsten geht das natürlich nicht und man muss mit den Fragmenten leben)

[Demivec]

2. LinkedList-Speicherverwaltung

[Vi-P]

Vielen Danke für die Antworten.
Daß die Map- und List-Elemente fix bleiben, das ist schon mal eine gute Nachricht. Strings haben mich in dem Zusammenhang der Vollständigkeit halber interessiert. Hätte ja auch sein können, daß intern ein String auch nur ein Zeiger ist und somit quasi fix hätte bleiben können. Trotzdem gut zu wissen. Wenn man einen fixen Zeiger auf einen String braucht, dann einfach in eine Struktur packen.

Zu 4: es wäre jetzt schon interessant, wie PB den Speicher verwaltet. Ob z.B. für Strings eigene Blöcke vom System angefordert werden und diese Blöcke nur für Strings verwendet werden. Damit könnte ein bisweiliges Freigeben von Listen und Maps den Speicher ordentlich aufräumen und wieder für das Betriebsystem zugänglich machen. Wird der Speicher gemischt für alles mögliche benutzt, sind dann möglicherweise überall in den von Listen und Maps verwendeten Speicher Strings eingestreut. Diese könnte PB im Zuge eines cleanups natürlich verschieben, und Blöcke zur Freigabe ausräumen. (Stringadr sind nicht fix wie wir gelernt haben) Ansonsten ist die Wahrscheinlichkeit gering, daß Speicher ans System zurückgegeben werden kann. Allerdings würde die Größe der freien Blocks steigen, die wieder unfragmentiert gefüllt werden könnten. Also, wenn jemand noch sicheres Wissen zu der Thematik hat, wäre dieses herzlich willkommen.

[STARGÅTE]

Trotzdem gut zu wissen. Wenn man einen fixen Zeiger auf einen String braucht, dann einfach in eine Struktur packen.

Nein, dass geht auch nicht! Zwar bleibt der Strukturzeiter der selbe, wenn man den String ändert, aber die String-Adresse selbst ändert sich wieder!

[Josh]

Eine Stringvariable ist genau genommen ein Zeiger auf einen Zeiger auf einen String. Das hat folgenden Hintergrund:

Wenn du den String änderst, kann sich ja auch die Länge des Strings ändern und es wird ein neuer Speicherbereich belegt. Damit nicht alle Stringvariablen, die auf diesen String zeigen, geändert werden müssen, wird ein weiter Zeiger zwischengeschaltet. Dieser 'Zwischenzeiger' bleibt immer an der gleichen Speicherposition und wenn der String selbst seine Speicherposition ändert, braucht die aktuelle Speicherposition des Strings nur in diesem 'Zwischenzeiger' geändert werden. Alle Stringvariablen verweisen immer auf diesen 'Zwischenzeiger'.


Eine Stringvariable mit fester Länge ist allerdings nur ein Zeiger auf den String, da dieser seine Speicherposition nie ändert.

[STARGÅTE]

Vorsicht Josh. Was meinst du mit "Stringvariable"?
Wenn ich in PureBasic einen String mit "Define String.s" definiere, dann wird mit bei @String der Zeiger auf den String zurückgegeben und nicht auf die Variable. Anders ist das bei "Define String.String".

Code: Alles auswählen

Define FixedString.s{100000}
Define StringVariable.s
Define StringStructure.String

Debug @FixedString        ; Feste Adresse zu einem Speicherblock
Debug @StringVariable     ; Variable Adresse zu einem Speicherblock (zu beginn Null!)
Debug @StringStructure    ; Feste Adresse zu einer Interger die die variable Adresse zu einem Speicherblock des Strings enthält
Debug @StringStructure\s

FixedString = "Hallo Welt!"
StringVariable = "Hallo Welt!"
StringStructure\s = "Hallo Welt!"

Debug "---"
Debug @FixedString
Debug @StringVariable     ; Variable Adresse zu einem Speicherblock (nun erstellt)
Debug @StringStructure
Debug @StringStructure\s

FixedString = Space(100000)
StringVariable = Space(100000)
StringStructure\s = Space(100000)

Debug "---"
Debug @FixedString        ; bleibt gleich
Debug @StringVariable     ; ändert sich
Debug @StringStructure    ; bleibt gleich
Debug @StringStructure\s  ; ändert sich

[Josh]

Mit Stringvariable meine ich 'Text$' oder wie auch immer ein String benannt wird. 'Text$' ist wie jede andere Variable ja nichts anderes als ein Synonym für einen Zeiger auf einen Speicherbereich, wobei bei Stringvariablen der Zeiger nicht direkt auf den String geht, sondern eben über einen 'Zwischenzeiger' (Ich spreche hier nicht von Strings mit fester Länge). Also ein Zeiger auf einen Zeiger auf einen String.

Was @ als Unary-Operator zurück gibt, hat mit dem gar nichts zu tun. Da hat Fred eben festgelegt, dass dieser Operator direkt den Speicherplatz des Strings zurück gibt und nicht den Speicherplatz des 'Zwischenzeigers', weil es eben logisch und sinnvoll ist.

[Vi-P]

Danke Leute, habe jetzt viel über die Speicherverwaltung von PB gelernt.
Danke auch für die zahlreichen Zugriffe. Es zeigt mir, daß das Thema nicht uninteressant war und ich wohl auf die Aussagen vertrauen kann.
Bzgl. der String Zeiger auf Zeiger Angelegenheit wäre meine Theorie, daß hier eine zentrale Verwaltung zwischen geschaltet wurde, möglicherweise (noch) nicht implementiert ist, um bei den Strings zwischendurch mal den Speicher optimieren zu können.
Bzgl. Möglichkeiten zur Speicherdefragmentierung werde ich wohl Versuche machen müssen. Wenn was interessantes dabei raus kommt, melde ich mich hier wieder.