Nova - in Rust geschriebene JavaScript- & WebAssembly-Engine

• Nova ist eine JavaScript-Engine mit datenorientiertem Design und verwendet eine Architektur, die darauf ausgelegt ist, Leistung und Cache-Effizienz zu maximieren
  • Sie zielt zugleich auf die Vermeidung von Speicherlücken und auf Performance-Optimierung ab
• Hauptmerkmale:
  • Alle im JavaScript-Heap allokierten Daten werden in typspezifischen Vektoren gespeichert (Zahlen im Zahlenvektor, Strings im String-Vektor usw.).
  • Heap-Referenzen werden als nach Typ getrennte Indizes verarbeitet, was Speichersicherheit und Größeneffizienz bietet.
  • Objekte werden nach Typ getrennt und in Vektoren gespeichert (gewöhnliche Objekte, Arrays, DataView usw.).
  • Nicht-gewöhnliche Objekte sind so konzipiert, dass sie nur bei Bedarf auf Daten gewöhnlicher Objekte verweisen.
  • Objekte werden aggressiv getrennt gespeichert, um das Lesen ungenutzter Daten zu vermeiden.
• Befindet sich noch in Entwicklung. Die Engine ist funktional noch stark eingeschränkt und besteht derzeit nur etwa 47 % der test262-Testsuite

[GN⁺]

Hacker-News-Kommentare

• Die Diskussion über architektonische Entscheidungen ist interessant, aber den meisten Leuten fehlt der Vergleichskontext. Im Vergleich zur Architektur von V8 ist schwer zu verstehen, welche Vorteile das bringt
• Ich habe schon über Projekte wie einen Lisp-Interpreter nachgedacht und dabei einige wesentliche Vorteile identifiziert
  • Einheitliche Allokation bedeutet, dass es keine Ausrichtungslücken gibt
  • Vorteile linearen Zugriffs bei der Garbage Collection
  • Kleinere Indizes statt Zeiger
  • Nach Typ getrennte Indizes können Platz sparen
• Ein Vergleich mit V8 muss nicht sofort erfolgen. V8 ist ein Projekt in Milliardenhöhe
• Es wäre vielleicht gut, sich die JS-Engine von Fabrice Bellard anzusehen
• Die Art der Datenallokation in V8
  • Alle Daten werden in einem von mehreren Heap-Bereichen allokiert
  • Heap-Referenzen sind echte Zeiger oder, bei Verwendung von Pointer Compression, ein Offset von der Heap-Basis
  • Objekte in V8 enthalten alle benötigten Daten und werden meist in einer einzelnen Allokation gespeichert
• Data-oriented Design wird davon bestimmt, wie auf Daten zugegriffen wird. Ich frage mich, warum man annimmt, dass typischer Datenzugriff ein linearer Zugriff auf Objekte desselben Typs ist
• „Zahlen landen in einem Zahlenvektor“ ist nicht üblich. JS-Engines verwenden normalerweise NaN-boxing oder inline kleine Ganzzahlen
• Ich frage mich, ob die Verwendung von NaN-boxing in Betracht gezogen wurde. Ich frage mich auch, ob die typbasierten Vektoren von der GC komprimiert werden oder ob eine Freiliste gepflegt wird
• Ich empfehle, „Don’t Stop the BIBOP: Flexible and Efficient Storage Management for Dynamically Typed Languages“ zu lesen
• Ich frage mich, ob diese JS-Engine experimentell ist oder versucht, die gesamte ECMAscript-Spezifikation zu implementieren
• Ich verfolge das Rust-Boa-Projekt, denke aber, dass es noch nicht produktionsreif ist
• Der data-oriented Ansatz und typbasierte Vektoren unterscheiden sich deutlich von traditionellen Architekturen wie V8
  • Performance in realen Szenarien: Ich frage mich, ob es Benchmarks gibt, die Nova mit V8 oder SpiderMonkey in Szenarien vergleichen, die komplexe und nichtlineare Datenzugriffsmuster enthalten
  • Trade-offs bei der Garbage Collection: Ich frage mich, ob Vektorwachstum und Komprimierung zu Speicherfragmentierung oder Performance-Engpässen führen können
• Ich frage mich, ob ein bestimmtes Anwendungsprofil im Blick ist
  • Könnte nützlich sein, um eine Scripting-Engine in Spiele einzubetten
• Ich frage mich, was das Wort „kind“ in „kind-specific vectors“ bedeutet
  • Ich frage mich, ob function X(a) { this.a = a; } und function Y(b) { this.b = b; } als unterschiedliche Objektarten betrachtet werden
  • Ich frage mich, ob bei der Erzeugung von Objekten per Literal {a: 1} und {b: 2} als unterschiedliche Objektarten betrachtet werden