Java Performance Tools – Teil 1 (Grundlagen)

Sonderdruck
hinzugefügt oder ein bestehender Code
verändert. Der Zeitpunkt der Manipulation
ist allerdings je nach verwendeter
Technologie unterschiedlich. Bei der statischen
Bytecode-Instrumentierung wird
der Bytecode vor dem Laden der Klassen
mit einem Preinstrumentor instrumentiert.
Der Bytecode läuft daher auf jeder
JVM und es werden keine zusätzlichen
Anpassungen oder Libraries zur Laufzeit
benötigt. Nachteilig ist, dass ein manueller
Schritt für die Instrumentierung notwendig
ist und Systemklassen des Runtime
Environment nicht instrumentiert
werden können.
Bei der Load-Time-Bytecode-Instrumentierung
wird ein eigener Class-
Loader verwendet, der beim Laden
einer Klasse den entsprechenden Bytecode
einfügt. Alternativ kann auch ein
JVMPI-oder JVMTI-Agent verwendet
werden, um beim entsprechenden Classloading
Event den Inhalt der Klasse zu
verändern. Man spart also im Gegensatz
zum statischen Ansatz einen manuellen
Schritt und kann auch Systemklassen instrumentieren.
Dynamische Bytecode-Instrumentierung
erlaubt es, den Bytecode einer Klasse
auch nachdem sie bereits geladen ist, zu
verändern. Diese Möglichkeit existiert
erst seit Java 5 und wird daher erst von
sehr wenigen Tools unterstützt. Das dynamische
Instrumentieren von Klassen
wird durch die RedefineClasses-Funktion
in JVMTI möglich. Neben JVMTI bietet
Java 5 aber auch eine reine Java-Implementierung
von Agenten für die dynamische
Instrumentierung von Bytecode,
die sich im Paket java.lang.instrument
befindet. Eigene Agenten zu schreiben, ist
relativ einfach, aber nicht nur für Performance-Messungen
sinnvoll, deshalb soll
nachfolgend beispielhaft die Implementierung
eines Agenten in Java beschrieben
werden.
Das Package java.lang.instrument
bietet Agenten die Möglichkeit, den
Bytecode von Klassen dynamisch zu
verändern. Die Manipulation des Bytecodes
kann auf zwei Wegen geschehen.
Zum einen zur Ladezeit durch eine Implementierung
des Interfaces ClassFile-
Transformer. Zum anderen zur Laufzeit,
das heißt, auch nachdem Klassen bereits
durch einen ClassLoader geladen wurden.
Letzteres geschieht durch die Methode
redefineClasses(), welche im Interface
Instrumentation definiert ist. Zur Veranschaulichung
soll ein einfacher Agent
entwickelt werden, der beim Laden jeder
Klasse eine Meldung mit dem Namen der
Klasse auf der Konsole ausgeben soll.
Die Dokumentation des java.lang.instrument-Pakets
gibt eine Übersicht über
Anforderungen an einen Agenten und
wie dieser eingebunden wird. Um einen
eigenen Agenten zu entwickeln, wird eine
Bootstrap-Klasse benötigt. Diese muss
über eine Methode mit einer Signatur verfügen,
die vergleichbar mit der main-Methode
für Java-Applikationen ist:
public static void premain(String agentArgs,
...
}
Instrumentation instrumentation){
Der Methode werden die Parameter für
den Agenten übergeben sowie eine Instanz
vom Typ java.lang.Instrumentation,
die Funktionen zur Instrumentierung von
Java-Klassen bietet. Die Veränderung des
Bytecodes erfolgt entweder über eine eigeneClassFileTransformer-Implementierung
für die Manipulation beim Laden
oder Redefinition der Klasse oder direkt
über eine neue Klassendefinition vom
Typ ClassDefinition, wenn eine Klasse
geändert werden soll, die bereits geladen
ist. Wird der Bytecode einer bereits geladenen
Klasse mit der redefineClasses()-
Methode überschrieben, hat dies nur
Auswirkungen auf zukünftig aufgerufene
Instanzen der Klasse. Instanzen der Klasse
die sich in einem aktiven Stack Frame
befinden, bleiben von der Änderung unberührt.
In dem Beispiel wird ein eigener
ClassFileTransformer verwendet, um
die Namen der geladenen Klassen auf die
Konsole zu schreiben und sie dann unverändert
weiterzureichen. Die Implementierung
des Interface benötigt nur eine
Methode:
package de.codecentric.transformer;
import java.lang.instrument.ClassFileTransformer;
import java.lang.instrument.IllegalClassFormatException;
import java.security.ProtectionDomain;
public class LogClassFileTransformer implements
ClassFileTransformer {
public byte[] transform(ClassLoader loader,
String className,
Class classBeingRedefined,
ProtectionDomain protectionDomain,
byte[] classfileBuffer)
throws IllegalClassFormatException {
System.out.println(
“Transformiere die Klasse ‘“ + className + “’“);
return null;
}
}
Nachdem der LogClassFileTransformer
mit addTransformer() bei der Instrumentation-Instanz
registriert wurde, wird bei
jeder Definition oder Redefiniton einer
Klasse die Methode transform(…) aufgerufen.
Eine Klassendefiniton erfolgt
über ClassLoader.definineClass() während
Klassenredefinitionen über Instrumentation.redefineClasses()
erfolgen.
Innerhalb der Methode ist es möglich,
den Bytecode der Klasse zu verändern.
Der Bytecode muss dem Classfile-Format
der JVM-Spezifikation [2] entsprechen.
An dieser Stelle bieten sich zur vereinfachten
Manipulation verschiedene
Open-Source-Tools wie Apache BCEL,
ObjectWeb ASM [3] oder JBoss Javassist
[4] an. In unserem Beispiel wird die
Klasse nicht verändert, weshalb in der
transform()-Methode null zurückgeliefert
wird. Der Code für den Agenten
sieht wie folgt aus:
package de.codecentric.instrument;
import java.lang.instrument.Instrumentation;
import de.codecentric.transformer.
LogClassFileTransfor-
Sonderdruck www.javamagazin.de
mer;
public class JMVTIAgent {
public static void premain(String agentArguments,
Instrumentation instrumentation) {
}
}
instrumentation.addTransformer(
new LogClassFileTransformer());
Der Agent kann jetzt mit jeder beliebigen
Java-Anwendung zusammen gestartet