Macht es Sinn ? Multithreaded Server in Delphi ?

[HamsterTrainer]

Hallo Zusammen,

Ich hab mal ne "dumme" Frage :-)
Macht es Sinn einen Multithreaded Server in Delphi zu Programmieren ?

Normalerweise bekommt ja jeder Client seinen eigenen Thread ... nun hab ich aber schon öfter hier gelesen das 16 Threads die praktikable Obergrenze sind ( sagt sogar Borland ) !!!

wie bekomme ich dann einen Server hin .... der bedeutend mehr Clients verwalten kann ( bis ca 100-200 ) ?

Oder wie ist diese Obergrenze von 16 Threads zu verstehen ?

Es soll mal ein Gameserver ( für ein MORPG ) werden ...der Positionsdaten...und vieles mehr mit den Clients austauscht.

Hat schon jemand Erfahrung mit einem Server unter Delphi ?

bis dann mal
Hamster

[Nicolai1234]

Zitat:

Zitat von HamsterTrainer

Macht es Sinn einen Multithreaded Server in Delphi zu Programmieren ?

Nein :wink:

Zitat:

Deutsch ist die Sprache der Macher und des Machens. Das fängt bei der Geburt an (den ersten Schrei machen) und endet mit dem Tod (den Abgang machen). Dazwischen kann man das Frühstück machen und die Wäsche, einen Schritt nach vorn und zwei zurück; man kann Pause machen, Urlaub oder blau, eine Reise ins Ungewisse und plötzlich Halt; man kann eine gute Figur machen und trotzdem einen schlechten Eindruck; man kann den Anfang machen, seinen Abschluss machen, Karriere machen; man kann drei Kreuze machen, Handstand oder Männchen machen; man kann die Nacht durchmachen, ein Opfer kalt machen, Mäuse, Kies und Kohle und sich ins Hemd machen; man kann andere zur Schnecke machen und sich selbst zum Affen; man kann sogar Unsinn machen - aber Sinn?

Quelle: Der Dativ ist dem Genitiv sein Tod

Sorry fürs OT :oops:

[Lemmy1]

Generell würde ich eher zu .Net oder Java tendieren. Managed Code hat gerade bei Servern große Vorteile (Stabilität, Speicherfragmentierung). Außerdem kann man seine Objekte in einen Applikationsserver packen und wird dadurch theoretisch skalierbarer.

Zwischen Java und .Net gibt es auch wieder Vor- und Nachteile: Java ist generell offener und Applikationsserver sind kostenlos. Dafür ist es verglichen mit C# verdammt hässlich (fehlende Properties, schlechtere Source-Docs, schlechtere #regions etc etc).

Ich muss aber zugeben, dass dies "nur gefühlte Erfahrungswerte" (gibt's sowas?) sind. Einen echten Server hab ich mit C# schon geschrieben, nicht aber mit Delphi/Win32...

Nachtrag: Bei so einem komplexen Thema würde ich aber trotzdem sagen: Selber Ausprobieren und viel viel simulieren :)

[alzaimar]

Um das Problem der Threadanzahl in den Griff zu bekommen, verwendest Du am Besten einen Thread-Pool. Aus einer Menge von z,B, 10-16 Threads wird pro Anfrage (natürlich nicht pro Connection) ein Thread genommen. Ist der Pool leer, weil alle Threads gerade im Einsatz sind, müssen die anderen warten.

Grundsätzlich würde ich aber fertige Lösungen nehmen. Ich stand vor dem gleichen Problem und mittlerweile setzen wir auf Tomcat. Als Übungsaufgabe (und da lernst Du eine MENGE) ist das aber eine interessante Aufgabe.

[snapman]

Zitat:

Zitat von alzaimar

Um das Problem der Threadanzahl in den Griff zu bekommen, verwendest Du am Besten einen Thread-Pool. Aus einer Menge von z,B, 10-16 Threads wird pro Anfrage (natürlich nicht pro Connection) ein Thread genommen. Ist der Pool leer, weil alle Threads gerade im Einsatz sind, müssen die anderen warten.

Grundsätzlich würde ich aber fertige Lösungen nehmen. Ich stand vor dem gleichen Problem und mittlerweile setzen wir auf Tomcat. Als Übungsaufgabe (und da lernst Du eine MENGE) ist das aber eine interessante Aufgabe.

Das enttäuscht mich aber sehr....wusste garnicht das Delphi so "mies" ist und nichtmal 17 Threads handeln kann :(

Wie stehts denn mit Delphi .NET ...hier sollte es ja gehen oder?

[DGL-luke]

Zitat:

Zitat von Nicolai1605

Zitat:

Zitat von HamsterTrainer

...

Nein :wink:

Zitat:

...

Sorry fürs OT :oops:

You don't think that makes sense?

:mrgreen:

[sakura]

Wenn Du die Indy-Tools nutzt und deren Implementation solltest Du eigentlich keine Probleme haben. Man kann auch mehr als 16 Threads nutzen, dass stellt kein Problem dar. Allerdings sollte man, wie oben bereits gesagt, nicht für jeden Client einen Thread ganzzeitig erstellen, sondern nur zur aktuellen Abfrage. Indy macht das für Dich.

...:cat:...

[negaH]

Im PortScanner-Thread hier in der DP habe ich klar gezeigt das man viel mehr als 16 Threads benutzen kann, zb. auf Win2k über 2000 Threads ! Und das in Delphi.

Warum sollte Delphi schlechter sein als JAVA oder C# oder irgendeine andere Sprache wenn es tatsächlich nur um eine Begrenzung im Betriebssystem geht ? Die Frage wäre dann korrekt wenn man "Windows mit zb. Linux" vergleichen würde.

Mit INDY hast du schon die richtige Wahl getroffen. Das unterstützt schon Thread-Pools, berücksichtig die zur Verfügung stehenden Resourcen transparent und autom. Lass dich also nicht verwirren und konfiguriere einfach die INDY Komponenten, fertig.
Davon mal abgesehen ändert ein Thread-Pool nichts an der Limitation der verfügbaren Threads, sondern beschleunigt nur die Re-/Allokation der Threads.

Gruß Hagen

[generic]

vieleicht sind threads nicht die richtige archiktektur ?

schau mal in die vorletzte C't dort war etwas über Schachspielen drin.
Dort auf der Seite gab es etwas über die Software zu lesen.

[Lemmy1]

Zitat:

Zitat von negaH

Warum sollte Delphi schlechter sein als JAVA oder C# oder irgendeine andere Sprache wenn es tatsächlich nur um eine Begrenzung im Betriebssystem geht ? Die Frage wäre dann korrekt wenn man "Windows mit zb. Linux" vergleichen würde.

a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf

Ich sage hiermit nicht, dass Delphi per se schlechter ist. Ich antworte nur auf die Frage, warum es Unterschiede geben KÖNNTE. Ob man sie praktisch spürt sei mal dahingestellt.


Grüße
Daniel

[alzaimar]

Zitat:

Zitat von negaH

Im PortScanner-Thread hier in der DP habe ich klar gezeigt das man viel mehr als 16 Threads benutzen kann, zb. auf Win2k über 2000 Threads ! Und das in Delphi.

Vermutlich stammt diese Zahl aus den Anfängen von Delphi, wo 486er noch gang und gäbe waren. Weiterhin dürften von 2000 Threads bei einem Portscanner 1999 warten, insofern sollte das nicht das Problem sein. Nur 2000 ständig laufende Threads zwingen nun jeden Computer in die Knie.

Zitat:

Zitat von negaH

Davon mal abgesehen ändert ein Thread-Pool nichts an der Limitation der verfügbaren Threads, sondern beschleunigt nur die Re-/Allokation der Threads.
Gruß Hagen

Na nee: Ich definier mir ein Array von Threads. Die werden niemals terminieren (außer bei Programmende). Ein Busyflag zeigt an, ob ein Thread gerade beschäftigt ist, oder nicht. Und wenn ein neuer Request von außen kommt, schau ich in der Liste nach, welcher denn frei ist. Der wird aktiviert und bearbeitet den Job. Wenn keiner frei ist, warte ich.

[smudo]

Zitat:

Zitat von HamsterTrainer

Ich hab mal ne "dumme" Frage Smile
Macht es Sinn einen Multithreaded Server in Delphi zu Programmieren ?

Das ist übrigens wirklich eine dumme Frage. :zwinker:
Weil eine Frage keinen Sinn machen kann. Sie kann Selbigen nur haben.
"Macht Sinn" kommt übrigens aus dem Englischen "Make sense".

Der manchmal klugscheißende :warn: René der gerade "Der Dativ ist dem Genitiv sein Tod" lesen tut.

[negaH]

Zitat:

a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

b) ändert nichts an der Tatsache, verschlimmbessert es sogar nur noch. Denn Threads sind auf Windows DIE Alternative wenn man asynchrone Sockets benutzen will. Und asynchrone Sockets benutzt man unter Windows zur TCP/IP Kommunikation deshalb weil diese mit den vorhandenen Sempahoren/Events (Signaling) zusammenarbeiten und diese wiederum nur mit Threads einen Sinn ergeben. Möchte man also sauber eine asynchrone und nicht-gepollte Socket Kommunikation haben, die das Gesamtsystem nur minimal belastet, so benötigt man unter Windows eben Threads. Verzichtet man darauf wie zb. in JAVA so kann man auch nicht mehr diese Art der Kommunikation des Betriebssystemes benutzen und zwangsläufig erhöht sich die Gesamtlast des Systems.

Das Einzigste was mir als Alternative einfallen würde ist das man innerhalb eines Threads mehrere Client-Sockets abarbeitet. Das ist dann aber keine Frage des OS oder der Programmiersprache mehr sondern nur eine Frage der Bibliothek die man benutzt zur Kommunikation. Sprich INDY oder was anders. INDY benutzt halt soviel wie ich weiß für jeden Client einen eigenen Thread. Ich persönlich arbeite nur damit (in kommerziellen Projekten) und hatte damit noch nie Probleme mit der Serverlast. Allerdings ist eine handfeste Aussage in diesem Punkt sehr schwierig, egal mit welchen Tools/OS man arbeitet. Eine wirklich sichere Aussage wirst du nur bekommen wenn du selber dein System unter Last real testest.

Gruß Hagen

[SubData]

Randinfo: Eine saubere, neue Apache Installation verwendet standardmäßig 250 Worker Threads für die Abarbeitung der Anfragen...

[negaH]

Zitat:

Na nee: Ich definier mir ein Array von Threads. Die werden niemals terminieren (außer bei Programmende). Ein Busyflag zeigt an, ob ein Thread gerade beschäftigt ist, oder nicht. Und wenn ein neuer Request von außen kommt, schau ich in der Liste nach, welcher denn frei ist. Der wird aktiviert und bearbeitet den Job. Wenn keiner frei ist, warte ich.

Hm ;) und meine Aussagen beziehen sich immer auf das Gesamtsystem. In diesem Falle gehe ich davon aus das die Socket Funktionen clevererweise die asynchrone/signaling Schnittstelle benutzen. Das ist der Weg den auch INDY geht und der die geringste Last produziert wenn man zb. auf Sockets, COM, USB etc.pp Schnittstellen warten muß. Unter Windows wohl gemerkt.

Aus dieser Sicht ist ein Thread-Pool erstmal direkt vergleichbar mit einer direkten Limitierung der zur Verfügung stehenden Sockets. Ob ich also nur 16 Threads in einem Pool alloziere = 16 Client-Sockets oder direkt nur 16 Sockets zulasse ist somit gleich bedeutend. Der einzisgte Unterschied ist nur das

1.) diese 16 Threads beim OS prealloziert werden können, sprich Resourcen reserviert werden
2.) die Allokationen solcher Pool-Threads sich beschleunigt, wie bei einem Cache.

Von der Limitation der Anzahl der Verbindungen her gesehen ist es aber gleich. Nur diesen Modus unterstützt INDY meines Wissens nach in seinem Pool.

Zitat:

Vermutlich stammt diese Zahl aus den Anfängen von Delphi, wo 486er noch gang und gäbe waren. Weiterhin dürften von 2000 Threads bei einem Portscanner 1999 warten, insofern sollte das nicht das Problem sein. Nur 2000 ständig laufende Threads zwingen nun jeden Computer in die Knie.

Stammen aus Delphi 5 Zeiten. Und exakt darum gehts hier auch bei der Frage. Denn in einer Socket Kommunikation ist eben das Warten auf Daten die zeitlich gesehen häufigste Operation. Es geht also um Serverlast und wie man diese gleichmäßig unter Windows verteilt. Und das geht über Threads die die meiste Zeit schlafen und erst aufwachen wenn sie asynchron durch das Socket API per Events aufgeweckt werden.

Ob nun 2000 Clientthread-Sockets auf einem Windowssystem mit JAVA, Delphi oder C# alloziert werden ist dabei irrelevant. Entscheidend ist das API das das OS zur Verfügung stellt. Hier also das Socket API und dessen Signaling und eben Threads.

Der Hinweis von Sakura ist also absolut korrekt, bezogen auf INDY.

Entweder eine andere Blibliothek statt INDY benutzen die es ermöglicht asynchron auf viele Sockets innerhalb weniger Threads zuzugreifen, oder eben wie Sakura es sagte die Zeitspanne der Clientverbindungen so kurz wie möglich halten. Das bedeutet das an an seinem Kommunikationprotokoll arbeiten muß. Sprich Sessionorientierte Clientverbindungen die zum Datenaustausch eben keine permanente Clientconnection benutzen sondern diese immer dynamisch aufbauen, Daten übertragen und sofort wieder abbauen.

Dies ist sowieso eine sehr gute Idee, egal ob man Windows oder Linux benutzt. Ich selber benutze nur diese Art der Kommunikation in meinen Systemen und wir hatten damit noch nie Serverlast Probleme. Viel kritischer waren da schon die Verbindungen zum SQL Server, der hat wirklich Nerven gekostet.

Gruß Hagen

[Lemmy1]

Zitat:

Zitat von negaH

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

Naja in einem Managed Heap kann man ja auch mal Objekte im Speicher verschieben (sprich: Defragmentieren). Insofern sehe ich dort das Problem als gelöst bzw fast gelöst an. Ich sag ja auch nicht, dass man immer in Probleme läuft. Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Zitat:

Zitat von negaH

b) ändert nichts an der Tatsache, verschlimmbessert es sogar nur noch. Denn Threads sind auf Windows DIE Alternative wenn man asynchrone Sockets benutzen will. Und asynchrone Sockets benutzt man unter Windows zur TCP/IP Kommunikation deshalb weil diese mit den vorhandenen Sempahoren/Events (Signaling) zusammenarbeiten und diese wiederum nur mit Threads einen Sinn ergeben. Möchte man also sauber eine asynchrone und nicht-gepollte Socket Kommunikation haben, die das Gesamtsystem nur minimal belastet, so benötigt man unter Windows eben Threads. Verzichtet man darauf wie zb. in JAVA so kann man auch nicht mehr diese Art der Kommunikation des Betriebssystemes benutzen und zwangsläufig erhöht sich die Gesamtlast des Systems.

Meine Aussage bezog sich ja nur darauf, dass es prinzipiell Unterschiede geben KANN. Da Du Dich offensichtlich mehr mit der Materie beschäftigt hast will ich Dir in diesem Fall ja auch gar nicht wiedersprechen :)

Zitat:

Zitat von negaH

Gruß Hagen

Grüße zurück

[sakura]

Zitat:

Zitat von Lemmy1

Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Keiner mit Verstand wird es tun, da ein Delphi-Server wohl immer auf Windows laufen wird und MS für Windows i.A. einmal im Monat den Patch'n-Reboot-Day veranstaltet :mrgreen: Aber zwei Monate (Email-Server auf Indybasis) ist meiner Erfahrung nach auch kein Problem.

...:cat:...

[Lemmy1]

Zitat:

Zitat von sakura

Zitat:

Zitat von Lemmy1

Aber ich hab halt auch noch nie einen Delphi-Server für 2 Jahre laufen lassen...

Keiner mit Verstand wird es tun, da ein Delphi-Server wohl immer auf Windows laufen wird und MS für Windows i.A. einmal im Monat den Patch'n-Reboot-Day veranstaltet :mrgreen: Aber zwei Monate (Email-Server auf Indybasis) ist meiner Erfahrung nach auch kein Problem.

...:cat:...

stimmt wohl.. :)

[negaH]

Zitat:

Meine Aussage bezog sich ja nur darauf, dass es prinzipiell Unterschiede geben KANN.

Ich weis und will dich und deine Meinung auch garnicht angreifen. Es geht darum WO die wirklich relevanten Unterschiede bei dem Problem eigentlich liegen, und das tuen sie

1.) beim Betriebsystem
2.) bei der Bibliothek die man zur Kommunikation benutzt -> INDY, Apache, Tomcat etc.pp.
3.) bei der Art und Weise wie man sein Protokoll aufbaut

Meiner Ansicht nach ist der 3. Punkt der entscheidende, egal welches OS, welche Programmiersprache oder Bibliothek man benutzt.

Zb. der Punkt das ein Server immer überlastet sein kann und wie dann das Protokoll darauf reagiert. Ist dieser Zustand in der Protokoll-FSM vorgesehen ? Wird der Client im Protokoll darüber informiert ? Bekommt der Client dann Informationen über seine Zeitscheiben um gezielt zu einem späteren Zeitpunkt seine Verbindung erneut aufbauen zu können ? Ist das Protokoll Sessionorientiert ? Verteilt der Server die zur Verfügung stehenden Resourcen geichmäßig auf die zu erwartenden Clients ?

Eines steht fest: egal was man benutzt technisch gesehen geht jeder Server in die Knie wenn er sehr viele Anfragen und Daten zur gleichen Zeit bekommt, ist ja zb. auch der Sinn einer DoS Attacke ! Ergo muß das benutzte Protokoll in jedem Falle auch darauf reagieren (bei wirklich großen Servern). Die einzigste Lösung in diesem Moment wäre eine Skalierung auf viele Servern um diese Last handeln zu können, denn die Grundlast exisitiert egal was man für Computer/Betriebsysteme/Bibliotheken und finally Programmiersprachen benutzt. Die Frage ist also nur ob die Bibliothek zur Kommnikation einem dabei unterstützt oder nicht.

Und INDY geht als Socket-Lib in diesem Punkt nicht weit genug, meiner Meinung nach :( Allerdings ist es auch nicht die Aufgabe einer Lib wie INDY solche Protokollspezifischen Sachen abzuhandeln. Somit ist ein Vergleich zwichen INDY und zb. Apache/Tomcat wiederum unfair, denn diese handeln eben solche Protokollsachen.

Gruß Hagen

[Elvis]

Zitat:

Zitat von negaH

Zitat:

a) Speicher-Fragmentierung
b) Java nutzt ein eigenes Thread-Management, und setzt nicht auf Betriebssystemthreads auf

a) muß zwangsläufig bei jedem Speichermanager auftreten. Speicherfragmentierungen sind auch garnicht das große Problem ansich.

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)

[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:

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. :angle2:

[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:

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:

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:

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:

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:

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:

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:

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 :stupid: .

Gruß
xaromz

[Elvis]

Zitat:

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. :mrgreen:

Zitat:

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:

Zitat von Elvis

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

Damit Du mich wieder volltexten kannst? Aber klar :zwinker: .

Gruß
xaromz