Was ist der Vorteil von Runtime GC gegenüber ARC zur Kompilierungszeit?

7

Einige neuere Sprachen implementieren ARC in ihre Compiler (Swift und Rust, um ein paar zu nennen). Wie ich verstehe, erreicht dies das gleiche wie Laufzeit-GC (die Last der manuellen Freigabe von dem Programmierer wegzunehmen), während es wesentlich effizienter ist.

Ich verstehe, dass ARC ein komplexer Prozess werden könnte, aber mit der Komplexität moderner Garbage-Collectors scheint es nicht mehr so ​​schwierig zu sein, ARC zu implementieren. Es gibt jedoch immer noch eine Vielzahl von Sprachen und Frameworks, die GC für die Speicherverwaltung verwenden, und sogar die Go-Sprache, die auf die Systemprogrammierung abzielt, verwendet GC.

Ich kann wirklich nicht verstehen, warum GC der ARK vorzuziehen wäre. Fehle ich hier etwas?

    
Mylin 09.09.2015, 04:16
quelle

1 Antwort

20

Es gibt eine Reihe von Kompromissen hier, es ist ein komplexes Thema. Hier sind die Großen:

GC-Profis:

  • Tracing-Garbage-Collectors können Zyklen in Objektgraphen verarbeiten. Die automatische Referenzzählung führt zu einem Speicherverlust, es sei denn, die Zyklen werden manuell unterbrochen, indem entweder eine Referenz entfernt wird oder ermittelt wird, welche Kante des Graphen schwach sein sollte. Dies ist ein ziemlich häufiges Problem in der Praxis in Bezug gezählten Apps.
  • Tracing-Garbage-Collectors können in Bezug auf den Durchsatz sogar moderat schneller sein als Referenzzählungen, indem sie gleichzeitig arbeiten, Batch-Arbeiten durchführen, Arbeiten verzögern und Caches, die Referenzzählungen berühren, in Hot-Schleifen nicht stören. li>
  • Das Kopieren von Sammlern kann den Heap komprimieren und fragmentierte Seiten wiederherstellen, um den Footprint zu reduzieren

ARC-Profis:

  • Da die Objektzerstörung sofort eintritt, wenn der Verweiszähler auf 0 steht, können Objektlebensdauern verwendet werden, um Ressourcen ohne Arbeitsspeicher zu verwalten. Bei der Speicherbereinigung sind die Lebensdauern nicht deterministisch, das ist also nicht sicher.
  • Die Sammlungsarbeit ist in der Regel stärker verteilt, was zu viel kürzeren Pausen führt (es ist immer noch möglich, eine Pause zu bekommen, wenn Sie einen großen Untergraphen von Objekten freigeben)
  • Da der Speicher synchron gesammelt wird, ist es nicht möglich, den Collector "zu überholen", da er schneller zugeordnet wird, als er aufräumen kann. Dies ist besonders wichtig, wenn VM-Paging ins Spiel kommt, da es degenerierte Fälle gibt, in denen der GC-Thread auf eine Seite trifft, die ausgelagert wurde und weit zurückfällt.
  • Zu diesem Zweck muss das Verfolgen von Garbage Collectors das gesamte Objektdiagramm durchlaufen, was unnötige Seiteneingaben erzwingt (dafür gibt es Abschwächungen wie Ссылка , aber sie sind nicht weit verbreitet)
  • Tracing-Garbage-Collectors benötigen in der Regel mehr "Scratch-Space" als Referenzzählung, wenn sie ihren vollen Durchsatz erreichen wollen

Meine persönliche Meinung ist, dass die einzigen zwei Punkte, auf die in den meisten Fällen wirklich ankommt sind:

  • ARC sammelt keine Zyklen
  • GC hat keine deterministischen Lebensdauern

Ich denke, dass diese beiden Probleme Deal-Breaker sind, aber in Ermangelung einer besseren Idee müssen Sie nur auswählen, welches schreckliche Problem sich für Sie noch verschlimmert.

    
Catfish_Man 09.09.2015, 04:36
quelle