Präambel
Hier geht es darum, die Effizienz der Nachrichtenübertragung in einem JIT-Compiler zu verbessern. Trotz der Bezugnahme auf Smalltalk gilt diese Frage für die meisten dynamischen JIT-kompilierten Sprachen.
Problem
Wenn eine Nachrichtensendestelle angegeben wird, kann sie als monomorph , polymorph oder megamorph klassifiziert werden. Wenn der Empfänger der Nachricht immer vom gleichen Typ ist, ist es ein monomorphes Senden, wie in
%Vor% wobei der Empfänger von new immer Object ist. Für diese Art von Sends emittieren JITs monomorphe Inline-Caches.
Manchmal bezieht sich eine bestimmte Sendestelle auf ein paar verschiedene Objekttypen, wie:
%Vor% In diesem Fall wird print an verschiedene Arten von Objekten gesendet. In diesen Fällen geben JITs normalerweise polymorphe Inline-Caches aus.
Megamorphe Nachrichten werden gesendet, wenn eine Nachricht nicht nur an einige wenige, sondern an viele viele Objekte an derselben Stelle gesendet wird. Eines der prominentesten Beispiele ist dies:
%Vor% Hier erstellt basicNew das Objekt, dann initialize führt die Initialisierung durch. Sie könnten tun:
und sie werden alle das gleiche Verhalten & gt; & gt; # neue Methode ausführen. Da die Implementierung von initialize in vielen Klassen unterschiedlich ist, wird der PIC schnell gefüllt. Ich bin an dieser Art von Sende-Sites interessiert, da sie wissen, dass sie nur selten vorkommen (nur 1% der Sends sind megamorph).
Frage
Was sind die möglichen und spezifischen Optimierungen für megamorphe Sende-Sites, um eine Suche zu vermeiden?
Ich stelle mir ein paar vor und möchte mehr wissen. Nachdem ein PIC voll ist, müssen wir die Suche aufrufen (sei sie voll oder die globale Zwischenspeicherung), aber zur Optimierung können wir:
Tags und Links optimization smalltalk performance jit vm-implementation