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.