Macht es Sinn ? Multithreaded Server in Delphi ?

[negaH]

Zitat:

Es muss nur in System auftreten, die keine Relokalisierung des Speichers ermöglichen.

Falsch, den es hat nicht zwangsläufig mit der Re-allokation von Speicher zu tuen sondern eine Fragmentierung kann schon auftreten bei simplen Allokationen. Fragmentierungen sind quasi "Löcher" im verwendbaren Speicherbereich die deshalb auftreten weil ihre Größe in Bytes zu keinen späteren Allozierungen passt. Wenn wir also nur einmal ein Object mit 10 Bytes allozieren, danach immer Objekte mit mehr als 10 Bytes und dann dieses 1 Objekt mit 10 Bytes freigeben dann besteht die Wahrscheinlichkeit das später diese 10 Bytes niemals wiederverwendet werden wenn

a.) kein weiteres Objekt a <= 10 Bytes alloziert wird
b.) die Objekte vor und nach dieser 10 Bytes Lücke niemals mehr freigegeben werden und somit sich diese 10 Bytes Lücke nicht durch Zusammenfassung freier Blöcke vergrößern kann

Heutige Speichermanager sind aber sehr effizient und dieses Problem ist vernachlässigenbar, bzw. wird meiner Meinung nach aus der Perspektive der Optimierungsmöglichkeiten überbewertet.

Gruß hagen

[Elvis]

Zitat von negaH:

Zitat:

Es muss nur in System auftreten, die keine Relokalisierung des Speichers ermöglichen.

Falsch, den es hat nicht zwangsläufig mit der Re-allokation von Speicher zu tuen sondern eine Fragmentierung kann schon auftreten bei simplen Allokationen. Fragmentierungen sind quasi "Löcher" im verwendbaren Speicherbereich die deshalb auftreten weil ihre Größe in Bytes zu keinen späteren Allozierungen passt.

Ich meinte es schon so wie ich es geschrieben habe. Sowohl Java als auch .Net Relokalisieren den Speicher. Dabei gruppiert zumindest .Net die Blöcke sogar so, dass gemeinsam benutzte Objekte beieinander liegen.
Der Flickenteppich von verwendeten und wieder freigegebenen Bereichen wird also in 2 homogene Blöcke zusammengeschoben. Da Speicher in beiden System allokiert wird, indem einfach die Grenzlinie von benutztem und freiem Speicher um die gewünschte Anzahl an Bytes verschoben wird, ist Relokalisierung sogar zwingend notwendig.

Es ist also kein wirklicher Nachteil von Delphi, und kein wirklicher Vorteil von Java/.Net.
Es ist eher Segen (sehr schnelle Bereitstellung von Speicher) und Fluch (Zwang zur Defragmentierung) in einem.

[negaH]

@Elivis:

Ich habe mal das Wort " Relokalisierung" nachgeschlagen, und es hat immer mit Lokalisierung zu tun, also mit "Ort".

Zitat:

Der Flickenteppich von verwendeten und wieder freigegebenen Bereichen wird also in 2 homogene Blöcke zusammengeschoben. Da Speicher in beiden System allokiert wird, indem einfach die Grenzlinie von benutztem und freiem Speicher um die gewünschte Anzahl an Bytes verschoben wird, ist Relokalisierung sogar zwingend notwendig.

Ok ich versuche das mal mit meinen Worten zu erklären, eventuell verstehe ich dich ja falsch.

Wir haben einen Speicher den wir in 2 Teile splitten. Der 1. Block enthält allozierte gültige Objekte der 2. Block enthält freien Speicher. Die Grenze zwischen diesen Blöcken stellt unsere Heapgrenze dar, also der Ort an dem ein neues Objekt seinen Speicher bekommmt. Wenn das so richtig ist dann ist dies ein stinknormales Verhalten eines jeden Speichermanagers. Ich sehe da jetzt keinen Unterschied der mit "Relokalsierung" -> "örtlichen Verschiebungen" zu tuen haben soll.

Denn eine dynamische Defragmentierung kann immer nur freie Speicherblöcke zusammenfassen wenn der Speichermanager die allozierten Blöcke ebenfalls zur Laufzeit verschieben kann. Dies bedeutet aber das alle Refernezen auf diese Speicherblöcke als indirekte Zeiger verwaltet werden müssen, da ansonsten bei direkten Zeigern diese ja nach der Defragmentierung ins Nirwana zeigen.

Bei JAVA als "interpretierende" Plattform ist das noch vorstellbar.


Gruß Hagen

[negaH]

Zitat:

dass gemeinsam benutzte Objekte beieinander liegen.

Was soll ich mir darunter vorstellen ? Ein Objekt liegt auf dem Speicher und wenn es mehrfach benutzt wird -> sprich mehrfach referenziert wird dann liegt denoch nur 1 Objekt im Speicher. Oder liegen mehrere Objekte im Speicher und der Laufzeitcode erkennt nun das davon x Objekte merhfach durch andere y Objekte benutzt werden und gruppiert sie dann entsprechend ? Wozu ? und wie erkennt der Code zur Laufzeit das diese Objekte mehrfach benutzt werden durch andere Objekte bzw. Zeiger darauf ?

Gruß Hagen

[xaromz]

Hallo,

Ich bin zwar nicht Robert, habe mich aber mit dem Speichermanager und dem Garbage Collector von .Net etwas beschäftigt. Deshalb antworte ich mal.

Zitat von negaH:

Wir haben einen Speicher den wir in 2 Teile splitten. Der 1. Block enthält allozierte gültige Objekte der 2. Block enthält freien Speicher. Die Grenze zwischen diesen Blöcken stellt unsere Heapgrenze dar, also der Ort an dem ein neues Objekt seinen Speicher bekommmt. Wenn das so richtig ist dann ist dies ein stinknormales Verhalten eines jeden Speichermanagers. Ich sehe da jetzt keinen Unterschied der mit "Relokalsierung" -> "örtlichen Verschiebungen" zu tuen haben soll.

Relokalisierung passiert natürlich erst, wenn der Speicher fragmentiert ist, und keine solche scharfe Grenze zwischen belegtem und freiem Speicher existiert. Dann kommt der Speichermanager und defragmentiert den Speicher, so dass eben dieser Zustand wieder hergestellt wird. Wie jeder gute Speichermanager benutzt natürlich auch der von .Net unterschiedliche Speicherblöcke für unterschiedliche Datengrößen.

Zitat von negaH:

Denn eine dynamische Defragmentierung kann immer nur freie Speicherblöcke zusammenfassen wenn der Speichermanager die allozierten Blöcke ebenfalls zur Laufzeit verschieben kann. Dies bedeutet aber das alle Refernezen auf diese Speicherblöcke als indirekte Zeiger verwaltet werden müssen, da ansonsten bei direkten Zeigern diese ja nach der Defragmentierung ins Nirwana zeigen.

Bei JAVA als "interpretierende" Plattform ist das noch vorstellbar.

Die Indirektion hat doch nichts mit interpretieren zu tun. Außerdem wird Java heutzutage eher selten interpretiert. Ganz im Gegenteil ist diese Indirektion ein integraler Bestandteil des Sicherheitssystems von .Net. Ohne diese könnte das so nämlich nicht funktionieren.

Zitat von negaH:

Was soll ich mir darunter vorstellen ? Ein Objekt liegt auf dem Speicher und wenn es mehrfach benutzt wird -> sprich mehrfach referenziert wird dann liegt denoch nur 1 Objekt im Speicher. Oder liegen mehrere Objekte im Speicher und der Laufzeitcode erkennt nun das davon x Objekte merhfach durch andere y Objekte benutzt werden und gruppiert sie dann entsprechend ? Wozu ? und wie erkennt der Code zur Laufzeit das diese Objekte mehrfach benutzt werden durch andere Objekte bzw. Zeiger darauf ?

Ich vermute, der MM macht letzeres. Er gruppiert Objekte, die z. B. zusammen von einem Elternobjekt erstellt wurden. Der Vorteil ist eigentlich recht einfach zu erkennen, beim Aufräumen des Speichers entstehen z. B. nicht drei kleine Lücken, sondern eine große. Das verhindert, dass der Speicher oft defragmentiert werden muss. Außerdem hängt das IMHO mit dem Garbage Collector zusammen, der Objekte nach ihrer bisherigen Lebensdauer gruppiert. Ich vermute, der übenimmt diese Gruppierung nebenher.

Gruß
xaromz

[negaH]

Zitat:

Ich vermute, der MM macht letzeres. Er gruppiert Objekte, die z. B. zusammen von einem Elternobjekt erstellt wurden. Der Vorteil ist eigentlich recht einfach zu erkennen, beim Aufräumen des Speichers entstehen z. B. nicht drei kleine Lücken, sondern eine große. Das verhindert, dass der Speicher oft defragmentiert werden muss. Außerdem hängt das IMHO mit dem Garbage Collector zusammen, der Objekte nach ihrer bisherigen Lebensdauer gruppiert. Ich vermute, der übenimmt diese Gruppierung nebenher.

Gut. Das heist aber auch das mit einem normalen MM wie der von Borland in einem Constructor eines Owner Objektes das mehrere Sub Objekte erzeugt diese ebenfalls linear im Speicher alloziert werden. Einfach auf Grund dessen das der freie Speicherblock sequientiell alloziert wird. Der Effekt wäre mit diesem MM der fast gleiche wie bei .NET ohne den nötigen Overhead. Anders ausgedrückt: der "veraltete" MM von Borland hat dieses Feature ebenfalls schon inklusive. Auch gruppiert er die Objekte anhand ihrer Größe in verschiedene Blöcke. Auch dieses Feature ist schon im "alten" MM von Borland drinnen. Übrigens wenn ich mich richtig erinnere wurde dieser MM von Borland schon seit Borland PASCAL 5 benutzt.

Gruß Hagen

[xaromz]

Hallo,

Zitat von negaH:

Gut. Das heist aber auch das mit einem normalen MM wie der von Borland in einem Constructor eines Owner Objektes das mehrere Sub Objekte erzeugt diese ebenfalls linear im Speicher alloziert werden. Einfach auf Grund dessen das der freie Speicherblock sequientiell alloziert wird.

Nein. genau durch die Fragmentierung des freien Speichers kannst Du davon eben nicht ausgehen.

Zitat von negaH:

Der Effekt wäre mit diesem MM der fast gleiche wie bei .NET ohne den nötigen Overhead. Anders ausgedrückt: der "veraltete" MM von Borland hat dieses Feature ebenfalls schon inklusive.

Nein, siehe oben.

Zitat von negaH:

Auch gruppiert er die Objekte anhand ihrer Größe in verschiedene Blöcke. Auch dieses Feature ist schon im "alten" MM von Borland drinnen.

Ich dachte, genau dieses Feature war mit ein Grund für den Wechsel auf FastMM.

Zitat von negaH:

Übrigens wenn ich mich richtig erinnere wurde dieser MM von Borland schon seit Borland PASCAL 5 benutzt.

Borland hat einen DOS-MM unter Windows eingesetzt? Jetzt wird mir einiges klar .

Gruß
xaromz

[Elvis]

Zitat von negaH:

Ok ich versuche das mal mit meinen Worten zu erklären, eventuell verstehe ich dich ja falsch.

Denke ich auch.

Zitat:

Die Grenze zwischen diesen Blöcken stellt unsere Heapgrenze dar, also der Ort an dem ein neues Objekt seinen Speicher bekommmt. Wenn das so richtig ist dann ist dies ein stinknormales Verhalten eines jeden Speichermanagers. Ich sehe da jetzt keinen Unterschied der mit "Relokalsierung" -> "örtlichen Verschiebungen" zu tuen haben soll.

Damit hast du aber die Tatsache unterschlagen, dass in einem deterministischen MM, in einem System ohne indirekte Zeiger, auch bereits freigegebene Bereiche unterhalb der Heapgrenze liegen.[1] Diese müssen von einem Delphi MM ebenfalls erfasst werden.
Wenn mich meine immer weiter schwindenden Kenntnisse von Delphis Internals nicht im Stich lassen, muss der Delphi MM durch eine verkettete Liste lauen um einen passenden Bereich zu finden. Die .Net GC inkrementiert tatsächlich nur einen Zeiger, der die Heapgrenze darstellt.

Zitat:

Denn eine dynamische Defragmentierung kann immer nur freie Speicherblöcke zusammenfassen wenn der Speichermanager die allozierten Blöcke ebenfalls zur Laufzeit verschieben kann. Dies bedeutet aber das alle Refernezen auf diese Speicherblöcke als indirekte Zeiger verwaltet werden müssen, da ansonsten bei direkten Zeigern diese ja nach der Defragmentierung ins Nirwana zeigen.

Kommt mir irgendwie bekannt vor.

Zitat von Elvis:

Es muss nur in System auftreten, die keine Relokalisierung des Speichers ermöglichen. Java und .Net können das, da dort eine Referenz ein indirekter Zeiger ist. (Der nach der Relokalisierung auf eine neue Adresse weiterverweisen kann)

Den Rest hat xaromz schon ausführlich genug erklärt.

btw: @xaromz, hoffentlich bist du beim nächsten Stammtisch wieder dabei.


[1]Sicherlich ist das vorübergehend auch in einem GC-basierten System der Fall, aber durch Relokalisierung kann die Heapgrenze immer wieder ein Stück zurückgesetzt werden.

[xaromz]

Hallo,

Zitat von Elvis:

btw: @xaromz, hoffentlich bist du beim nächsten Stammtisch wieder dabei.

Damit Du mich wieder volltexten kannst? Aber klar .

Gruß
xaromz