Perl Internals - Speicherverwaltung der VM

[Philipp Hasenfratz]

Halihallo zusammen

Zurück zum Thema: Ich weiss nicht, inwiefern Optimierungen vor/nach BEGIN durchgeführt
werden, oder welchen Einfluss sie auf das Alloziieren von Speicher hat. Ich hoffe, dass
ich das auch im genannten Thread gesagt habe. Ich könnte es mir vorstellen.
Fakt ist:
a) BEGIN/END sind keine normalen Prozeduren und können im Programm-Scope nicht als solche
   angesprochen werden (könnten also "speziell" gehandhabt werden).
b) Speicherallozierung ist Zeitaufwändig und wird von Perl wenn möchlich optimiert
   (eg. nicht mehr gebrauchte Variablen-Speicher (AV,SV,IV,HV,..) werden wiederverwendet)
was ich glaube ist:
a) Opcode-Optimizer startet vorher und somit wäre da der Zeitpunkt, wo Speicher
   für die PerlVM alloziiert wird (später wird Speicher durch perlinterne Makros
   verwaltet, falls Perl so kompiliert wurde, ggf. muss neuer Speicher vom OS
   geholt werden).
b) Wenn also bereits Module beim Startup eingelesen werden, könnten Variablen im
   Modul-Scope eigentlich beim Opcode-Optimizer erkannt werden und den Speicheraufwand
   beeinflussen (den virtuellen Speicher zu der PerlVM zu begin festlegen, sodass der
   Speicher nicht mehr zur Laufzeit vom OS angefordert werden muss und alles in einem
   Block alloziiert wird).

Sorry, ich rede einfach gerne über die Internals und Denke auch gerne darüber nach: ;)

nehmen wir ein kleines Script:

--
use strict;

our $test1= 'Philipp Hasenfratz';
our $test2= 'Hauptstrasse 3';
our $test3= '8259 Wagenhausen';

while ( my ($n,$v) = each %{main::} ) {
   print "$n => $v\n"
}
--

Wie man sieht, stehen die drei Variablen (und weitere) in der symbol-table des Moduls
main. Was, wenn wir ein Programm mit 10'000 Variablen hätten? - Beim optimizer wären
diese bereits sichtbar und es wäre wohl sehr performant, wenn gleich für alle Variablen
Speicher im "Packet" angefordert werden würde, ansonsten müsste Perl ca. 20'000
Memory-allocations durchführen, für Variablen, die evtl. nur 10 Bytes beanspruchen...
Ein alloziieren von 20'000 * 10 Bytes[1], also 200'000 Bytes wäre sehr viel schneller.

Was, wenn Module über 'use' eingebunden werden? - Der Parser lädt die Module ein, nachher
springt der Opcode-Optimizer an; dieser könnte nun die sym-table analysieren und den
minimalen Speicheraufwand errechnen und diesen gleich in einem Packet alloziieren.

Dann sollte man gleich noch einige KB's für Laufzeitvariablen alloziieren, denn die
VM's schmeissen mit Variablen rum, wie George W. mit Gewehrpatronen. Eine Optimierung
macht hier, wie ich denke, schon Sinn, aber leider sind Block-Scoped-Variablen (also
z. B. solche, die in einer Prozedur mit 'my' definiert werden) sehr viel verbreiteter
und diese können eben nicht im Startup erkannt werden, da sie eben erst zur Laufzeit
in den "Scope geraten" (iniziiert, geändert, zerstört).

Inwiefern - oder überhaupt - dies jedoch in Perl geschieht, weiss ich wie gesagt nicht,
leider, würde mich nämlich interessieren. Wie Perl mit den Variablen hantiert und was es
mit dem virtuellen Speicher von Perl auf sich hat, ist mir schon bekannt, aber ich kenne
die Optimierungen nicht.

Weiss vielleicht jemand geeignete Lektüre?

[1] Die Rechnung wiedergibt nicht die Realität, sondern dient nur dem Verständnis, in
    Wahrheit müssten noch weitaus mehr alloc's durchgeführt werden.

Viele Grüsse

Philipp