Ich experimentiere mit dem Schreiben einiger Bindungen zum Böhm GC für Rust.
Einige Hintergrundinformationen: Rust ist als Sprache mit hoher Nebenläufigkeit konzipiert, und ein Ergebnis dieses Designs ist die Fähigkeit, GC-Zeiger statisch auf die Threads zu beschränken, in denen sie zugewiesen wurden (d.h. ein GC-Zeiger, der in Thread x kann niemals von einem anderen Thread am Leben erhalten (oder überhaupt referenziert werden).
Daher möchte ich Boehm dazu bringen, dies für die Leistung so weit wie möglich zu nutzen:
- Thread-sicher, sodass ich mehrere Threads zuweisen und sammeln kann
- Stoppen Sie Sammlungen so wenig wie möglich (dh nur den aktuellen Thread), können andere Threads weiterlaufen, da sie möglicherweise nichts stören können, was für die GC-Zeiger außerhalb ihrer selbst relevant ist
- vorzugsweise vollständig Thread-lokal ohne Synchronisation zwischen den GC-“Instanzen” verschiedener Threads
1 ist einfach, aber ich kann keine Möglichkeit für 2 und 3 finden. Der wichtigste Teil ist 1 & 2, weil ich in der Lage sein möchte, Threads im Hintergrund laufen zu lassen, unabhängig davon, was die anderen Threads tun (auch wenn sie alle ordnen Gigabyte Speicher zu und sammeln Datenmüll ein).
(Ich tue wissen über THREAD_LOCAL_ALLOC & gc_thread_local.haber das erfüllt 3 nicht ganz, es macht es nur effizienter, aber es ist immer noch gültig, die Thread-lokal zugewiesenen Zeiger zwischen Threads zu übertragen, obwohl ich diese Garantie nicht benötige.)
Sind Sie entschlossen, Boehm zu verwenden, oder sind Sie bereit, andere konservative Open-Source-GCs auf dem Markt in Betracht zu ziehen? Beispielsweise können Sie Tamarins MMgc hier in etwas Passendes für Ihre Bedürfnisse hacken. (Meiner Erinnerung nach erlaubt MMgc GC-Objekte pro Thread, jedes mit seinen eigenen Wurzeln und Objektgraphen.)
– pnkfelix
6. Januar 2014 um 9:43 Uhr
(Als Follow-up zu MMgc: Es gibt immer noch einen globalen Cross-Thread-Status in einer GCHeap-Klasse und auch eine globale Pagemap; ich bin mir nicht sicher, wie weit Sie mit Ihrem dritten Kriterium gehen wollen. Außerdem gibt es das Problem, dass Adobe ist wahrscheinlich keine große Unterstützung für dieses Projekt.)
– pnkfelix
6. Januar 2014 um 9:51 Uhr
@pnkfelix Ich bin zu nichts verpflichtet, ich experimentiere nur mit “einfachen” GCs (und ich könnte es genauso gut im Kontext von Rust tun, obwohl Leute wie Sie weitaus mehr wissen als ich 🙂 ). Das sieht so aus, als wäre es machbar, aber ich bin nicht sehr daran interessiert, eine C-Schnittstelle zu schreiben, die über FFI verwendet werden kann (obwohl ich es auf jeden Fall als Möglichkeit zur Untersuchung im Hinterkopf behalten werde, danke). Auf jeden Fall hacke ich jetzt einen reinen Rust GC zusammen; Es ist einfacher, alle oben genannten Anforderungen zu erfüllen, und es macht sowieso mehr Spaß: aber es ist viel schwieriger, annähernd so schnell zu sein, daher bin ich immer noch an Antworten auf diese Frage interessiert.
– huon
7. Januar 2014 um 0:54 Uhr
Falls es seit der Frage neu ist, nur für Follower:
-DPARALLEL_MARKgithub.com/ivmai/bdwgc/blob/master/doc/scale.md es gibt auch inkrementelle mit Zeitlimit (auf Kosten der parallelen Markierung) github.com/ivmai/bdwgc/commit/…– Rogerpack
10. September 2019 um 16:14 Uhr