JOL – analiza obiektów JVM

Co to jest JOL?
JOL (Java Object Layout) to mały zestaw narzędzi do analizy obiektów w JVM. Narzędzia te wykorzystuje Unsafe, JVMTI i Serviceability Agent (SA) do dekodowania rzeczywistego układu obiektów i referencji. Dzięki temu JOL jest znacznie dokładniejszy niż inne narzędzia bazujące na zrzutach sterty, założeniach specyfikacji itp.
Jak się do niego dobrać?
Dodajemy sobie zależność do maven’a:

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.9</version>
</dependency>

Aby dobrać się do wirtualnej maszyny mamy do dyspozycji taką klasę:

org.openjdk.jol.vm.VM

Która ma jedną statyczną metodę publiczną:

VirtualMachine.current()

Zwraca obiekt typu:

org.openjdk.jol.vm.VirtualMachine

Dzięki tej klasie mamy możliwość dobrać się do danych JVM np:
Odpalenie czegoś takiego:

VM.current().details();

Daje nam informacje o maszynie wirtualnej, np:

# Running 64-bit HotSpot VM.
# Using compressed oop with 3-bit shift.
# Using compressed klass with 3-bit shift.
# WARNING | Compressed references base/shifts are guessed by the experiment!
# WARNING | Therefore, computed addresses are just guesses, and ARE NOT RELIABLE.
# WARNING | Make sure to attach Serviceability Agent to get the reliable addresses.
# Objects are 8 bytes aligned.
# Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

Jak chcemy sprawdzić wielość nagłówka obiektu w pamięci wystarczy wpisać:

VM.current().objectHeaderSize()

Sprawdzenie czy dana klasa jest adnotowana przez adnotacje @Contended:

ContendedSupport.isContended(StandardObject.class)

W pakiecie JOL mamy również do dyspozycji kilka klas utils:

org.openjdk.jol.util.ClassUtils

umożliwiający dynamiczne ładowanie klas, również w systemowych ClassLoaderze

org.openjdk.jol.util.IOUtils

util pozwalający bezpiecznie zamykać strumienie

org.openjdk.jol.util.MathUtil

kilka matematycznych operacji

org.openjdk.jol.util.Multiset

Klasa opakowująca java.util.HashMap służąca jako inkrementer

org.openjdk.jol.util.ObjectUtils

w klasie są dwie metody, value i safeToString. Metoda value wyciąga wartość dla wybranego pola z klasy na trzy różne sposoby, metoda safeToString wykonuje toString() na typach array i primitive
Za pomocą dostępu do VM możemy wyciągać dużo szybciej dane z obiektów za pomocą „refleksji” – a tak na prawdę bezpośrednio odwołując się do pamięci.
Przykładowy benchmark:

Setup dla benchmarka:

private StandardObject object;
private Field field;
private VirtualMachine vm;
private long offset;

@Setup
public void setup () {
    object = new StandardObject();
    object.setVal(100.0);
    vm = VM.current();
    try {
        field = StandardObject.class.getDeclaredField("val");
    } catch (NoSuchFieldException e) {
        e.printStackTrace();
    }
    offset = vm.fieldOffset(field);
}

Standardowe wyciąganie danych przez refleksje:

@Benchmark
public void reflect () {
    try {
        field.setAccessible(true);
        blackhole.consume(field.get(object));
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Wyciąganie danych bezpośrednio z pamięci

@Benchmark
public void reflectVM () {
    try {
        blackhole.consume(vm.getDouble(object, offset));
    } catch (Exception e) {
        e.printStackTrace();
    }
}

Wynik benchmarku:

Benchmark                Mode  Cnt       Score      Error   Units
BenchmarkApp.reflect    thrpt    5  159966.722 ± 4850.180  ops/ms
BenchmarkApp.reflectVM  thrpt    5  259729.201 ± 6932.689  ops/ms

Wynik pokazuje, że możemy spokojnie zastosować JOL do wyciągania danych za pomocą refleksji. Oczywiście może to być istotne w sytuacji gdy wykonuje po kilka set a nawet tysięcy takich operacji na sekundę.
Analiza obiektów za pomocą JOL:
Sprawdzanie adresu obiektu:

VM.current().addressOf(obiekt);

Sprawdzanie wielkości obiektu, w przypadku obiektów złożonych nagłówka:

VM.current().sizeOf(obiekt);

Wyświetlanie danych o obiekcie:

GraphLayout.parseInstance(obiekt).toPrintable();

Wynik:

net.szwadron.StandardObject@47d384eed object externals:
          ADDRESS       SIZE TYPE                        PATH                           VALUE
        782a82d58         24 java.lang.String            .string                        (object)
        782a82d70         96 [C                          .string.value                  [f, s, d, f, d, s, f, d, s, f, d, s, s, d, d, s, d, s, c, d, v, d, s, v, 2, 3, r, 2, 3, e, 2, 3, e, d, w, d, 2, 3]
        782a82dd0         24 java.lang.String            .standardObject.string         (object)
        782a82de8        112 [C                          .standardObject.string.value   [f, s, d, f, d, s, f, d, s, f, d, s, s, d, d, s, d, s, c, d, v, d, s, v, 2, 3, r, 2, 3, e, 2, 3, e, d, w, d, 2, 3, e, w, r, e, w, r, w, e]
        782a82e58         24 (something else)            (somewhere else)               (something else)
        782a82e70         24 net.szwadron.StandardObject                                (object)
        782a82e88        384 (something else)            (somewhere else)               (something else)
        782a83008         24 java.lang.Double            .val                           10.0
        782a83020         24 net.szwadron.StandardObject .standardObject                (object)

Wyświeltenie tylko i wyłacznie wilkości:

GraphLayout.parseInstance(obiekt).toFootprint();

Wynik:

net.szwadron.StandardObject@47d384eed footprint:
     COUNT       AVG       SUM   DESCRIPTION
         2       104       208   [C
         1        24        24   java.lang.Double
         2        24        48   java.lang.String
         2        24        48   net.szwadron.StandardObject
         7                 328   (total)

Sprawdzenie całkowitej ilości obiektów:

GraphLayout.parseInstance(obiekt).totalCount();

No i na koniec sprawdzenie tylko wielkości obiektów:

GraphLayout.parseInstance(obiekt).totalSize();

Zwraca nam sumę wszystkich obiektów. Oczywiście wszystkie te dane mamy również wyżej, ale jeśli chcemy mieć jakieś metryki z wielkości danych jakie przetwarzamy lub wiedzieć ile pamięci potrzebujemy to ostatnia metoda w pełni nam to ogarnie.
Na koniec tylko wspomnę, że w JOL również mamy coś takiego jak HeapDumpReader który pozwala nam załadować do pamięci dumpa pamięci JVM i go analizować, czyli jakby ktoś chciał sobie napisać własnego analizera do pamięci.
Źródło:
http://openjdk.java.net/projects/code-tools/jol/