>>145452>Das ist eher eine Kompiler- bzw. Implementationsfrage
Naja, da steht schon "real existierend", was sich auf eine Implementierung beziehen sollte.
Bei C/C++: Gibt nur 3 in Frage kommende Implementierungen, und zwar ähnlich gute Implementierungen.
Bei müllabführenden Sprachen: Gibt in der Regel (C#, Java, JavaScript) einen Platzhirsch, ansonsten nehme die dir genehme Implementierung.
Wobei die Implementierung natürlich egal ist, weil alle Müllabfuhr-basierten Sprachen, in egal welcher Implementierung, huntslahmer Müll sind
(
nicht ganz ernst gemeint,
oder doch?)
>SBCL ist mit Typdeklarationen z.B. heute schon gut im Rennen.
Ich mag das Bankmarken-Spiel nicht, aber da ist SBCL ungefähr Faktor 5x lahmer, was für eine JavaScript-Maschine den absoluten Tod bedeuten würde (bei JavaScript-Maschinen wird darum gekämpft, wer 5-10 % schneller als die JavaScript-Konkurrenz ist).
https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html
>Die Anforderung ist kompletter Unsinn. Sind in Felixens Welt alle Müllabfuhren seriell und halten die Welt an?
Genau das war ja beim Käfer der Fall. Wenn man den Brauserinhalt gescrollt hat, ist buchstäblich ein Streifen vom Bildausschnitt mit Fensterhintergrundfarbe gefüllt worden, und erst nach dem Ende der Müllabfuhr, 7 Sekunden später, wurde der Bildinhalt gerendert und ging es weiter. Das hängt auch damit zusammen, dass JavaScript einzelfadig ist - wenn der eine, einzige JavaScript-Faden stoppt, ist auch die Seite eingefroren.
>Currently, all modern engines ship a mark-and-sweep garbage collector. All improvements made in the field of JavaScript garbage collection (generational/incremental/concurrent/parallel garbage collection) over the last few years are implementation improvements of this algorithm, but not improvements over the garbage collection algorithm itself nor its reduction of the definition of when "an object is no longer needed".
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_management
So, und nun die Frage: Wenn der JavaScript-Faden gerade läuft, wie soll man währenddessen von einem anderen Faden auf die Objekte in der JavaScript-Maschine zugreifen, während die Maschine gerade ausgeführt wird und diese Objekte manipuliert und neue Objekte erstellt/die Referenzen zwischen diesen Objekten umbiegt? Genau, dafür braucht man entweder einen Globalen-Interpretierer-Lock (CPython) oder feingranulare Locks/Mutexe, die bei jeder solchen Stelle im JavaScript-Interpretierer den Interpretierer sperren. Und sperren bedeutet Jank.
Weiteres Problem: Die Müllabfuhr muss ja auf irgendeinem Faden laufen (Endgegner: System hat nur 1 Kern), und wenn alle Fäden bereits vom Brauser belegt sind, und die Müllabfuhr laufen soll, muss einer der anderen Fäden anhalten. Dann stoppt hoffentlich nicht der aktuelle Tab, weil der ja gerade in Benutzung ist. Aber hoffentlich auch kein Hintergrundtab, in dem gerade ein DuRöhre-Video abgespielt wird, und dann die Musik stoppt, wenn die Müllabfuhr zu lange dauert und die JavaScript-Engine nicht mehr die Audio-API füttert. Jedenfalls hat C# extreme Probleme mit Müllabfuhr, wie man bei Unity sieht, und die müssen große Klimmzüge unternehmen, um die Müllabfuhr und den damit einhergehenden Jank/Spikes zu umgehen:
https://embrace.io/blog/garbage-collector-spikes-unity/
In Unity sind ~5 ms bereits eine inakzeptable Zeit für die Müllabfuhr, weil das länger als ein ganzer Frame auf einem guten Monitor ist. Ein Brauser soll aber so flüssig wie eine Spiele-Maschine laufen. Lösung in Unity ist natürlich, native Allokationen und Deallokationen, die die Müllabfuhr nicht sieht, zu benutzen. Also diesbezüglich keine Müllabfuhr zu benutzen.
>Welche real existierende müllabführende Programmiersprache bietet überhaupt [...]?
Aber ich entnehme deiner Antwort, dass es aktuell keine hier verwendbare Programmiersprache dafür gibt.