Ich verstehe, dass diese Frage in die Implementierung spezifischer Bereiche eingeht, aber an dieser Stelle würden Rakudo / MoarVM spezifische Antworten auch mir helfen.
Ich arbeite an einigen NativeCall-Modulen und frage mich, wie man Speicherlecks beheben kann. Etwas Speicher wird in der C-Bibliothek behandelt, und ich habe dort einen guten Griff. Ich weiß, dass diese Domäne in meiner Verantwortung liegt und es gibt nichts, was MoarVM da drüben tun könnte. Was kann ich in der MoarVM-Domain tun? Was ist der beste Weg, um nach dangelnden Objekten, Zirkelverweisen usw. zu suchen?
Gibt es einen Weg am Ende einer Reihe von Operationen, bei denen ich denke, dass alle meine Perl-Objekte nicht in der Lage sind zu sagen: "Führen Sie Garbage Collection aus und erzählen Sie mir von allem, was übrig ist?"
Gibt es Rakudo / NQP / MoarVM spezifischen Code, den ich ausführen kann, um mir zu helfen? Dies ist nicht in der Produktion zu veröffentlichen, nur für Tests / Diagnosen, während ich mich entwickle.
Garbage Collection in MoarVM gibt einen verlockenden Überblick, aber nicht genug Informationen für mich etwas damit zu machen.
Erstens, während der ausgelaufene Speicher auf der C-Seite in diesem Fall nicht dein Problem ist, solltest du wissen, dass Rakudo ein perl6-valgrind-m installiert, das das Programm unter valgrind ausführt. Ich habe dies mehrmals verwendet, um Seg-Fehler und Lecks beim Schreiben nativer Bibliotheks-Bindungen herauszufinden.
Wenn Sie nach Objekten suchen, die von MoarVM verwaltet werden, ist es möglich, dass die VM Halden-Snapshots ausgibt. Sie werden nach jedem GC-Lauf genommen und ein zusätzlicher GC-Lauf wird erzwungen und ein endgültiger Schnappschuss wird am Ende des Programms erstellt. Um Snapshots aufzuzeichnen, starte mit --profile=heap . Die Ausgabedatei kann dann an moar-ha übergeben werden, die mit zef install App::MoarVM::HeapAnalyzer installiert werden kann (sie ist in Perl 6 implementiert, was Sie vielleicht wissen sollten, wenn Sie sie auf irgendeine Weise erweitern möchten, um Ihre Probleme zu lösen) / p>
Wenn Sie wissen, welche Art von Objekten möglicherweise leckt, kann es nützlich sein, nach Objekten dieses Typs mit dem Befehl find zu suchen. Es gibt dann einen path -Befehl, der zeigt, wie das Objekt am Leben erhalten wird. Es kann auch nützlich sein, die Anzahl der Objekte zwischen verschiedenen Heap-Snapshots zu betrachten, um zu sehen, was im Gebrauch wächst. Leider gibt es noch kein Snapshot-Diff-Feature.
Beachten Sie, dass die Snapshots alles enthalten, was auf der VM ausgeführt wird. Das bedeutet, dass sich der Perl 6-Compiler im Speicher befindet, sowie eine Reihe von Objekten für Dinge aus den Sprach-Einbauten. (Das Tool wurde entwickelt, um verwaltete Lecks im Compiler und in den eingebauten Komponenten aufzuspüren, daher wird dies als Feature betrachtet. :-) In Zukunft könnte jedoch eine Art Filterung möglich sein.)
Schließlich haben Sie Zirkelbezüge erwähnt. In Perl 6 sind diese Probleme kein Problem, da GC durch Nachverfolgung und nicht durch Referenzzählung erfolgt.
Tags und Links garbage-collection perl6 nativecall