Wir sind gerade dabei, einem unserer Produkte eine serverseitige Skriptfunktionalität hinzuzufügen. Als Teil davon werte ich JSR 223 Script-Engines aus. Da wir möglicherweise eine große Anzahl von Skripts auf dem Server ausführen, mache ich mir besonders Gedanken über die Speichernutzung dieser Skriptmodule. Beim Vergleich von Rhino (Apple JDK 1.6.0_65-b14-462-11M4609, Mac OS X 10.9.2) mit Nashorn (Oracle JDK 1.8.0-b132) scheint es einen dramatischen Unterschied in der Speicherauslastung pro ScriptEngine-Instanz zu geben.
>Um dies zu testen, verwende ich ein einfaches Programm, das 10 leere ScriptEngine-Instanzen startet und dann das Lesen von stdin blockiert. Dann benutze ich jmap, um einen Heap-Dump zu machen (jmap -dump: format = b, file = heap.bin) und suche dann nach der relevanten Script-Engine-Instanz im Dump:
%Vor%Der Grund für das Ausgleichen der verschiedenen Leser / Schreiber-Felder im Kontext liegt darin, dass wir sie nicht verwenden, und frühere Heap-Dumps für Rhino legen nahe, dass sie einen erheblichen Anteil des pro Instanz verursachten Overheads ausmachen (und nicht erscheinen geteilt werden).
Wenn ich diese Heap-Dumps in Eclipse MAT analysiere, bekomme ich die folgenden, pro Instanz beibehaltenen Heap-Größen:
Ist diese 24-fache Vergrößerung für Nashorn zu erwarten? Die Ausführungsgeschwindigkeit ist für die Skripte, die wir ausführen werden, nicht von großer Bedeutung (was meistens E / A-gebunden sein wird), daher erwäge ich, unsere eigene Kopie von Rhino zur Verwendung in Java 8 + zu verschicken.