Auf Spurensuche in der Java-VM

Transkript

1 Auf Spurensuche in der Java-VM In der jüngeren Vergangenheit ist in der Java-Welt eine Art von Werkzeugen entstanden, die sich zwischen den Extremen "Debugging" und "Profiling" ansiedelt. Diese Werkzeuge erlauben es, das Verhalten von Anwendungen hinsichtlich eines sonst verdeckten Charakterzuges zu beobachten. Im Folgenden sollen zwei dieser TracingWerkzeuge an Hand von Beispielen vorgestellt werden. Tracing-Werkzeuge sind im Bereich der Systemadministration bereits bestens bekannt. So protokolliert beispielsweise maufrufe das eines Linux-Werkzeug "strace" Anwendungssystems in alle Syste- menschen- lesbarer Form. Tracing-Werkzeuge, die Ähnliches für Java Debug Interface (JDI) Java Virtual Machine Tool Interface (JVMTI) Java Pla orm Debugger Architecture (JPDA) Java-Anwendungen leisten wollen, können sich der JPDA Java Na ve Interface (JNI) (Java Platform Debugger Architecture) bedienen. Über die Virtual Machine JPDA-Schnittstelle JDI (Java Debug Interface) kann mittels eines Agenten, der in Java geschrieben ist, auf VM-Interna Java Debug Wire Protocol (JDWP) Abbildung 1: Die Java Platform Debugger Architecture zugegriffen werden (Abbildung 1). Dieser Agent kann all das tun, was auch ein Entwickler in einer Debug-Session tun Als Untersuchungsgegenstand soll das Logging-System von könnte nur wird das "Handeln" des Agenten durch ein EclipseLink dienen. Das Tracing soll ähnlich wie bei den Skript vorherbestimmt. Jeder Sun-SDK-Installation liegen Unix-Werkzeugen gemeinsam mit dem zu untersuchenden unter /demo/jpda/examples einige Beispiel-Anwendun- Programm gestartet werden. gen für JPDA bei. Das einfachste Beispiel ist "Trace" im Paket com.sun.tools.example.trace. Diese Trace-Anwendung ist BTrace bereits in die Bibliothek "tools.jar" einkompiliert und kann für erste Experimente sofort genutzt werden. Für BTrace ist der Ausgangspunkt eines Tracings die Definition eines Messpunktes (Probe-Point). Solche Messpunkte Java-Tracer können beispielsweise das Betreten oder das Verlassen von Methoden, das Ablaufen eines Timers oder ein Variablenzu- Zwei Open-Source-Projekte, die in die Kategorie "Tracing- griff sein. An diese Messpunkte können Skripte gebunden Werkzeuge" fallen, sind BTrace und YouDebug. Beide Pro- werden (Trace-Actions), welche die jeweiligen Messungen jekte werden auf Kenai gehostet [1] [2]. Für BTrace existieren durchführen. Ein solches Skript wird als statische Methode Plugins, die eine Einbindung in VisualVM und NetBeans (Action-Method) in Java-Klasse ermöglichen. YouDebug stammt aus derselben Feder wie definiert. Das in Abbildung 2 dargestellte Beispiel soll der "Hudson" und integriert Groovy zur Steuerung von Tracing- Veranschaulichung dienen. Sessions. Beide Werkzeuge sollen auf folgende Anwendungsfälle hin untersucht werden: Dieses Skript besagt, dass, wann immer eine Methode "log" in der Klasse "org.eclipse.persistence.logging.ab- Überwachung einer Methodenausführung stractsessionlog" betreten wird, der Text "Hit log method in Ausgabe der Methodenparameter AbstractSessionLog" ausgegeben werden soll. Der Klassen- Berechnung der Ausführungszeit name "LogTraces" und der Methodenname "hit" sind will- Manipulation eines Methodenparameters kürlich. Nicht willkürlich ist die Methoden-Signatur: Auf Spurensuche in der Java-VM. Seite 1

2 Möchte man eine Variable vom Typ "Array" public class LogTraces { geben lassen, so existiert hierfür eine weitere public static void hit(anytype[] args) { "Hit log method in AbstractSessionLog"); Abbildung 2: BTrace-Action Helfermethode die Benutzung von Schleifen ist aus Performance-Gründen in einer Action-Methode untersagt. Auf das erste Beispiel angewendet, sähe die Action-Methode damit wie in Abbildung 4 dargestellt aus. In diesem Beispiel wird zusätzlich mittels "BTraceUtils.jstack()" ein Stack-Trace ausgegeben. Auf diese Weise lässt Der Parameter "AnyType[] args" bewirkt, dass Log-Metho- sich einfach nachvollziehen, welche andere Methode die den mit beliebigen Methoden-Signaturen erfasst werden. Log-Methode aufgerufen hat. Der Parameter "args" enthält dann alle aktuellen ParameterWerte. Für die Berechnung der Ausführungszeit von Methoden hat die BTrace-Bibliothek bereits Vorkehrungen getroffen: Möchte man nur Methoden mit der Signatur "log(int, injiziert die Ausführungszeit in Nanosekunden erfassen, sähe die Action-Methode wie in Abbildung 3 aus. als Parameter. Zur Verfügung steht diese Information bei der Rückkehr aus einer Methode wie in Abbildung 5 dargestellt Die wesentliche Änderung zum vorhergehenden Beispiel ist die veränderte Methoden-Signatur. Darüber hinaus wurde die Implementierung der Action-Methode so erweitert, dass Eine manuelle Berechnung der Ausführungszeit ist auch sie gleichzeitig auch den Inhalt der Parameter ausgibt. Hier- möglich. Die Startzeit muss per Thread in einem Thread- bei ist es nicht möglich, den Plus-Operator für String-Verket- Local-Store abgelegt werden (Abbildung 6). tungen zu nutzen man muss in diesem Fall auf die statische Methode "BTraceUtils.strcat(String, String)" ausweichen. Möchte man die Ausführungszeiten aggregieren, um beispielsweise einen Durchschnitt zu berechnen, public static void hit2(int level, String message) { "Hit log method in AbstractSessionLog:"); BTraceUtils.strcat( BTraceUtils.strcat("level: ", BTraceUtils.str(level)), BTraceUtils.strcat(", message: ", message) ) ); Abbildung 3: BTrace-Action für "log(int, String)" kann man auch hier auf bestehende Helfermethoden zurückgreifen. Die einzelnen Messpunkte werden in einer "Aggregation" gesammelt (Abbildung 7). Die Angabe von "@Location(value = Kind.RETURN, clazz="/.*abstractsessionlog$/", method="/(?!log$).*/")" bewirkt hier, dass die Ausführungsdauer nur dann für die Berechnung herangezogen wird, wenn die aufrufende Methode nicht auch "log" heißt. Wenn eine Log-Methode public static void hit(anytype[] args) { "Hit log method in AbstractSessionLog:"); BTraceUtils.printArray(args); BTraceUtils.jstack(); Abbildung 4: BTrace-Action mit Array-Ausgabe und Stacktrace Seite 2. Auf Spurensuche in der Java-VM eine andere Log-Methode aufruft, würde die Ausführungszeit sonst mehrfach in die Berechnung einfließen. Der letzte Anwendungsfall die Manipulation von Methodenparametern ist mit BTrace nicht möglich. Innerhalb eines BTrace-Skripts kann

3 man zwar Zugriff auf Klassen- und Instanz-Felder erlangen, nicht aber auf Methodenparameter. Darüber hinaus wird durch die BTrace-Umgebung jeder Versuch vereitelt, Felder zu manipulieren und damit das untersuchte Programm zu beeinflussen. Mittels "unsafe=true" beim Kompilieren und Verwenden eines Action-Skripts kann diese Kontrolle abgeschaltet werden. ein Werkzeug namens "btrace" mitgeliefert. Mit seiner Hilfe kann man sich an einen laufenden Java-Prozess per PID koppeln und die Untersuchungen durchführen. Die Action-Skript-Klasse wird durch dieses Werkzeug automatisch kompiliert und per Class-Retransformation in den untersuchten Java-Prozess eingewoben. BTrace setzt hierfür auf ein proprietäres Verfahren außerhalb der JPDA. man allerdings das BTrace-Skript gleichzeitig mit der Anwendung ausführen, muss dieses vorkompiliert werden. Hierfür wird ein Werkzeug namens "btracec" mitgeliefert. Beim Starten der zu untersuchenden Anwendung muss ein Java-Agent als JavaVM-Startparameter angegeben ("-javaagent:btrace-agent.jar"). Dieser werden erhält dabei eine Referenz auf das vorkompilierte Skript. Alternativ kann man auch das Werkzeug "btracer" mit entsprechenden Start-Parametern nutzen. YouDebug Im Gegensatz zu BTrace nutzt das YouDebugWerkzeug ausschließlich die JDI-Schnittstelle für das Erlangen der Trace-Informationen. Um dem Anwender den lästigen Compile-Schritt zu ersparen, wird das Trace-Script nicht in Java, sondern in Groovy formuliert. YouDebug vereinfacht die Skript-Programmierung durch einen Groovyspezifischen JDI-Adapter. public static void long duration, int level, String message) { println(strcat("executing log method took [ns]: ", str(duration))); Abbildung 5: BTrace-Action mit Zeitmessung Für die Anwendung von BTrace-Skripten wird Möchte import static com.sun.btrace.btraceutils.println; import static com.sun.btrace.btraceutils.str; import static private static long starttime; location public static void hit3in(int level, String message) { starttime = BTraceUtils.timeNanos(); public static void hit3out(int level, String message) { long duration = BTraceUtils.timeNanos() - starttime; BTraceUtils.strcat("executing log method took [ns]: ", BTraceUtils.str(duration)) ); Abbildung 6: BTrace-Action mit Zeitmessung (Alternative) private static Aggregation logdurationavg = BTraceUtils.newAggregation( AggregationFunction.AVERAGE); location = Kind.RETURN, clazz="/.*abstractsessionlog$/", method="/(?!log$).*/")) public static void hit3out(@duration long duration) { BTraceUtils.addToAggregation(logDurationAvg, duration); "de.buschmais.example.elmain", method = "main", public static void exit(string[] args) { "-- Summary "); BTraceUtils.printAggregation("avg-log", logavg); Abbildung 7: BTrace-Action mit Berechnung von Durchschnittszeiten println "Hit log method in AbstractSessionLog"; ; Abbildung 8: YouDebug-Skript Auf Spurensuche in der Java-VM. Seite 3

4 Das Grundprinzip eines YouDebug-Skripts ist die Definition notwendig. Durch die enge Beziehung zum JDI-API und der unterschiedlicher Breakpoints. Innerhalb einer Closure wird somit verfügbaren Dokumentation ist dieser Schritt jedoch dabei die Tracing-Aktion festgehalten (Abbildung 8). gut zu meistern [3] (Abbildung 9). Dieser Breakpoint erfasst alle Log-Methoden unabhängig Ähnlich zum BTrace-Beispiel wird nicht nur der Inhalt der von ihrer Methoden-Signatur in der Klasse "AbstractSes- Methoden-Parameter ausgegeben, sondern gleichzeitig noch sionlog". Möchte man nur eine bestimmte Methode unter- der Call-Stack auf die Konsole herausgeschrieben. suchen, ist etwas mehr Programmieraufwand als bei BTrace Auch für die Berechnung der Ausführungszeit def inttype = vm.virtualmachine.mirrorof(1).type(); def stringtype = vm.ref("java.lang.string"); def signature = [inttype, stringtype]; com.sun.jdi.stackframe stackframe = thread.frame(0); argumenttypes = stackframe.location().method().argumenttypes(); if (argumenttypes == signature) { printf("level: %d, message: %s%n", stackframe.argumentvalues[0].value(), stackframe.argumentvalues[1].value()); thread.dumpthread(); ; Abbildung 9: YouDebug-Skript mit Parameter- und Stacktrace-Ausgabe def starttimes = new HashMap<String, Long>(); starttimes.put(vm.currentthread.name(), System.nanoTime()); ; vm.methodexitbreakpoint( duration = System.nanoTime() - starttimes.get( vm.currentthread.name()); printf ("executing log method took %d ns%n", duration); ; Abbildung 10: YouDebug-Skript mit Zeitmessung def inttype = vm.virtualmachine.mirrorof(1).type(); def stringtype = vm.ref("java.lang.string"); def signature = [inttype, stringtype]; com.sun.jdi.stackframe stackframe = thread.frame(0); argumenttypes = stackframe.location().method().argumenttypes(); if (argumenttypes == signature) { // 'level' heißt der Methoden-Parameter level = 6; // level = WARNING ; Abbildung 11: YouDebug-Skript mit Parameter-Manipulation Seite 4. Auf Spurensuche in der Java-VM einer Methode ist Handarbeit notwendig. Zu beachten ist hier unbedingt, dass im Gegensatz zu BTrace die untersuchende VM von der untersuchten VM getrennt ist. Das Konstrukt eines ThreadLocals muss daher nachgebaut werden (Abbildung 10). Möchte man ähnlich zum BTrace-Skript eine doppelte Zeiterfassung vermeiden, so kann man über das Konstrukt "thread.frame(1).location().method().name()" an den Methoden-Namen der aufrufenden Methode gelangen. Betrachtet man allerdings die erfassten Messwerte, wird schnell der negative Einfluss des Tracings auf das Zeitverhalten der Anwendung deutlich. Da eine sinnvolle Interpretation der Zeiten nicht möglich ist, soll im Weiteren von der Berechnung der Durchschnittszeiten Abstand genommen werden. Der letzte zu betrachtende Anwendungsfall die Manipulation der Ziel-VM kann mit YouDebug spielend gemeistert werden. Alle sichtbaren und benannten Variablen der Zielmethode werden in den Scope der Groovy-Closure eingeblendet (Abbildung 11). Bei Namenskonflikten kann per Pseudovariable "delegate" ein Zugriff auf die Variablen der Ziel-VM erlangt werden. Für das Beispiel wäre der Aufruf folglich "delegate.level". Ist das untersuchte Programm ohne Debug-Informationen kompiliert worden, ist ein Zugriff per Position als delegate."@0" möglich.

5 Die Manipulation von Methoden-Parametern ist dann aller- durch, bevor mit einer Messung begonnen werden kann. dings ausgeschlossen. Dieser Vorgang kann bei Application-Server-Anwendungen zu einer erheblichen Startverzögerung führen. Das Rüsten einer Anwendung für die Untersuchung mit YouDebug unterscheidet sich nicht von der Vorbereitung für Beide Werkzeuge unterscheiden sich auch in der Qualität Remote-Debugging. Per VM-Parameter muss lediglich der der verfügbaren Dokumentation. Obwohl YouDebug selbst JPDA-Debug-Agent aus dem Java-SDK aktiviert werden: nur wenig Dokumentation mitbringt, kann über die JDIDokumentation alles Wesentliche erschlossen werden. Die -agentlib:jdwp=transport=dt_socket,address=5005, server=y,suspend=y BTrace-Dokumentation stützt sich stark auf die mitgelieferten Beispiele. Allerdings sind in der aktuellen Version nicht alle Beispiele compile-fähig. Das Argument "suspend=y" bewirkt, dass erst beim Start der Debug-Session auch das Programm gestartet wird. Das Als Fazit lässt sich festhalten, dass Tracing-Werkzeuge eine YouDebug-Skript kann wie folgt ausgeführt werden: interessante Bereicherung des Werkzeugkastens eines Java-Entwicklers darstellen. Sie bieten sich immer dann an, java -jar youdebug-1.3-jar-with-dependencies.jar wenn ein Re-kompilieren der Anwendung mit zusätzlichen -socket 5005 Sysout-Printlns zu aufwändig wäre, um an die gewünschten LogDebug.ydb Informationen zu gelangen. Anders als bei den Pendants aus der Unix-Welt ist der Rüstaufwand jedoch nicht zu unter- Fazit schätzen. Frank Schwarz BTrace und YouDebug unterscheiden sich in der Herangehensweise für das Tracing einer Java-Anwendung. BTrace- Quellen Skripte werden per Byte-Code-Instrumentierung in die [1] BTrace: Ziel-VM gewoben und gemeinsam mit dem untersuchten [2] YouDebug: Programm ausgeführt. Zeitmessungen sind daher relativ [3] Java Debug Interface: verlässlich, die Manipulierbarkeit der Ziel-VM wird jedoch auf ein Minimum beschränkt. YouDebug-Skripte hingegen sind mit einer Remote-Debug-Session vergleichbar. Die Möglichkeiten, auf die Ziel-VM Einfluss zu nehmen, sind da- Kontakt her fast unbegrenzt. Zeitmessungen dürfen aber keinesfalls in absoluter Form interpretiert werden, da die Ziel-VM im buschmais GbR Debug-Modus stark ausgebremst wird. Leipziger Straße Dresden Die unterschiedliche Arbeitsweise der Tracing-Werkzeuge führt auch dazu, dass bei YouDebug erste Messergebnisse Tel +49 (0) relativ schnell vorliegen. BTrace hingegen führt zunächst Fax +49 (0) eine Retransformation aller geladenen Klassen der Ziel-VM Web Copyright 2010 buschmais GbR Alle Rechte vorbehalten. Java und alle Java-basierten Markennamen sind Markennamen oder registrierte Markennamen von Sun Microsystems, Inc. in den USA und anderen Ländern. Alle anderen Marken- und Produktnamen sind Markennamen oder registrierte Markennamen des jeweiligen Eigentu mers. buschmais ist eine eingetragene Marke der buschmais GbR. Ihre Verwendung im Geschäftsverkehr ist nur bei ausdrücklicher, schriftlicher Erlaubnis der buschmais GbR statthaft. Auf Spurensuche in der Java-VM. Seite 5