Interfejs w JVMie – niskopoziomowo

Standardowym pytaniem rekrutacyjnym jest: czym się różni interfejs od klasy abstrakcyjnej w Javie. O ile większość odpowiedzi zaczyna się od strony specyfikacji, o tyle w tym wpisie podejdę od strony implementacji.

Bytecode

Standardowo zaczniemy od spojrzenia w bytecode. Najpierw podejrzymy co siedzi w abstrakcyjnej klasie:

public abstract class AbstractClass {
    public abstract int doSth(int a);
    public int defaultDoSth(int a) {
        return doSth(a);
    }
}

Następnie podejrzymy analogiczny do niej interfejs:

public interface Interface {
    int doSth(int a);
    default int defaultDoSth(int a) {
        return doSth(a);
    }
}

Porównując obydwa twory zaczniemy od stwierdzenia banału, że po skompilowaniu otrzymujemy pliki z rozszerzeniem .class Gdzie zatem jest trzymana informacja o tym, że jedno jest interfejsem a drugie klasą? Na to pytanie odpowiada listing wywołania na tych plikachjavap -v -p.

A w nim zauważymy, że klasa abstrakcyjna posiada flagi flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT, gdy interfejs posiada flagi flags: (0x0601) ACC_PUBLIC, ACC_INTERFACE, ACC_ABSTRACT.
Zatem o byciu interfejsem świadczy dodatkowa flaga ACC_INTERFACE.
Flaga ACC_SUPERw klasie abstrakcyjnej jest aktualnie nadmiarowa i istnieje tylko w celu wstecznej kompatybilności.

Drugą różnicą, którą zauważyć porównując bytecode obu plików .class jest obecność konstruktora w klasie abstrakcyjnej. Jak wiemy, jeśli jawnie nie stworzymy konstruktora w kodzie źródłowym, kompilator wygeneruje nam domyślny konstruktor danej klasy.

Trzecią różnicą dość oczywistą, aczkolwiek niewidoczną w tym porównaniu jest to, że klasa w przeciwieństwie do interfejsu może posiadać pola.

Ostatnią różnicę, którą dokładniej opiszę jest różnica w implementacji metody defaultDoSth(int).

Dla klasy abstrakcyjnej bytecode wygląda następująco:

 public int defaultDoSth(int);
    descriptor: (I)I
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: iload_1
         2: invokevirtual #2                  // Method doSth:(I)I
         5: ireturn
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       6     0  this   Ldev/jgardo/jvm/miscellaneous/interfaces/AbstractClass;
            0       6     1     a   I
}

Domyślna metoda interfejsu Interface defaultDoSth(int) zdekomilowana wygląda tak:

  public int defaultDoSth(int);
    descriptor: (I)I
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=2, args_size=2
         0: aload_0
         1: iload_1
         2: invokeinterface #1,  2            // InterfaceMethod doSth:(I)I
         7: ireturn
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       8     0  this   Ldev/jgardo/jvm/miscellaneous/interfaces/Interface;
            0       8     1     a   I
}

W implementacji metody defaultDoSth(int) w przypadku klasy abstrakcyjnej widzimy instrukcję kodu bajtowego invokevirtual, a za nią parametr, w którym jest wskazywana metoda, którą chcemy wywołać.
W przypadku interfejsu zauważymy invokeinterface z dwoma parametrami.
A jakie są różnice między nimi? Czy były konieczne dwa różne kody operacji?

Invoke(…)

Ogólnie mówiąc, wywoływanie metod można wykonać za pomocą jednego z 5 różnych instrukcji kodu bajtowego (w zależności od kontekstu):

  • invokestatic – używamy go za każdym razem, kiedy wywołujemy metodę statyczną, czyli taką, w której nie potrzebujemy przekazywać wskaźnika na obiekt z którego jest ona wywoływana (nie ma przykazywanego w żaden sposób obiektu this).
  • invokespecial – tej instrukcji używamy, kiedy chcemy wywołać konkretną metodę danego obiektu. Nie zastanawiamy się, czy ta metoda jest nadpisana w klasie dziedziczącej, lecz wskazujemy dokładną metodę. Przykładem jest wywoływanie metody prywatnej, metody z nadklasy lub konstruktora. Przekazujemy niejawnie this jako pierwszy parametr metody.
  • invokedynamic – ta instrukcja jest raczej niedostępna w Javie i rzadko spotkana (oprócz lambd). Kluczowe jest w niej to, że generalnie na etapie kompilacji nie wiemy, co chcemy wywołać 😉 Na etapie kompilacji jedynie wskazujemy, kto może wiedzieć, co chcemy wywołać.
    Trochę poruszam temat we wpisie o lambdach.
  • invokevirtual – w tym przypadku mamy do czynienia z wywołaniami metod publicznych, chronionych i prywatnych w ramach pakiety (generalnie nieprywatnych). Na etapie kompilacji przeważnie nie wiemy, czy wywołujemy metodę z danej klasy, czy klasy po niej dziedziczącej (ze względu na polimorfizm). W runtime‚ie JVM ewaluuje, jaką metodę wykonać.
    W tej operacji równierz przemycamy this. Argumentem tego kodu bajtowego jest indeks metody, którą wywołujemy.
  • invokeinteface – bardzo podobna instrukcja do invokevirtual z tą różnicą, że nie znamy nawet klasy, której metodę wywołujemy. W tym przypadku jednak mamy dwa argumenty tego kodu bajtowego – pierwszym jest jawne przekazanie uchwytu („wskaźnika”) do interfejsu, którego metodę chcemy wywołać, a drugim – indeks tej metody w danym interfejsie.

Różnice między invokevirtual a invokeinterface

Jak wywnioskować, którą metodę należy wykonać?
Najprościej byłoby sprawdzić klasę (wskaźnik na klasę jest w każdym obiekcie w jego nagłówku), której metodę chcemy wywołać i poszukać, czy istnieje implementacja poszukiwanej metody. Jeśli nie ma jej w tej klasie, szukamy jej w nadklasie. Jeśli i w niej nie ma, szukamy dalej w zwyż w hierarchii.

Jednak takie podejście jest mało efektywne. Mogłoby się zdarzyć, że wielokrotnie obliczamy to samo wywołując wciąż tę samą metodę. Zatem lepiej by było na etapie ładowania klasy obliczyć od razu, jaką dokładnie metodę trzeba wykonać dla każdej dostępnej metody. Wynik takich obliczeń można składować w metadanych danej klasy.
I właśnie taka tablica, która przechowuje dla każdej metody wskaźnik do kodu, jest nazywana vtable. Zatem za każdym razem, gdy używamy invokevirtual, najpierw sprawdzamy klasę obiektu, następnie odczytujemy z klasy adres do pola z tablicą vtable, a następnie uruchamiamy kod znaleziony pod indeksem danej metody (indeks ten jest podany w argumencie invokevirtual).

Warto tutaj nadmienić, że indeksy metod dla danej hierarchii klas są takie same, tzn. jeśli jakaś klasa miała tablicę vtable, to każda jej podklasa będzie miała wszystkie jej metody z nadklasy w dokładnie tej samej kolejności, a ewentualne dodatkowe metody specyficzne dla podklasy będą znajdować się na końcu tabeli. Zatem jeden argument z indeksem metody wystarczy do precyzyjnego określenia metody, gdyż indeks metody w danej hierarchii klas jest stały.

Nieco inna sytuacja jest w przypadku invokeinterface. Jeśli klasa implementuje interfejs, to metody go implementujące mogą być w vtable w różnej kolejności. Zatem dla interfejsu potrzebujemy analogicznej struktury zwanej itable. Kolejność metod jest specyficzna dla danego interfejsu.
„Niestety” klasy mogą implementować wiele interfejsów, dlatego każda klasa posiada tablicę tablic itable. Skoro jest wiele itable, to trzeba je rozróżniać, stąd konieczność przekazywania wraz z kodem invokeinterface argumentu w postaci odniesienia do interfejsu, jak i metody.
Pewną konsekwencją możliwości implementacji wielu interfejsów jest to, że żeby znaleźć odpowiednią itable trzeba przeiterować po tablicy tablic itable, co jest mało wydajne.

Jeśli ten opis jest zbyt mglisty, warto zajrzeć pod ten pomocny w zrozumieniu link.

A to tylko początek

Można na ten temat jeszcze wiele pisać. Póki co jednak zostawiam garść linków omawiających tematy wokół. Dotyczą one przede wszystkim:

  • optymalizacji invokeinterface/invokevirtual.
    Należy wspomnieć, że znaczna większość interfejsów/klas posiada tylko jedną klasę implementującą lub jedną podklasę. Można się wówczas pokusić o optymalizację i skuteczne inline’owanie.
    Słowa klucze dla tego tematu to: monomorphic, bimorphic, megamorphic.
    Osobiście polecam wpis Aleksey’a Shipilev’a oraz Richarda Warburtona
  • opisu wywołań wirtualnych/interfejsu prosto ze strony OpenJDK
  • porównania wywołań wirtualnych w różnych językach
  • wydajności obu wywołań oraz o bugu, który nie pozwala inline’ować jedynej implementacji interfejsu

A na razie to by było ode mnie na tyle. Jeśli chcecie sami coś po kombinować z interfejsami źródła moich eksperymentów są na githubie. Dajcie znać w komentarzach, co o tym wszystkim myślicie 😉

 

Enum w JVM – szczegóły implementacyjne

Kolejnym słowem kluczowym, które chciałbym omówić jest enum. Ta konstrukcja została wprowadzona w Javie 1.5. Może się wydawać, że intuicyjnie wiemy, jak technicznie enum jest zaimplementowany, jednak warto zweryfikować domysły. Być może to słowo kluczowe niesie ze sobą jakieś dodatkowe „magiczne” właściwości, których zwykła klasa nie posiada…

Pierwsze spojrzenie na bytecode

Na początek stwórzmy i skompilujmy prostą klasę:

public enum Enum {
    VAL_1(1),
    VAL_2(2);

    private final int abc;

    Enum(int abc) {
        this.abc = abc;
    }
}

Następnie dekompilujmy ją z użyciem javap -v -p. Dekompilator wyświetla dosyć dużo linii, więc skupię się na tych ciekawszych rzeczach i krótko skomentuję. Cały listing na samym spodzie postu.

public final class dev.jgardo.jvm.miscellaneous.enums.Enum extends java.lang.Enum<dev.jgardo.jvm.miscellaneous.enums.Enum>

Jak widzimy, enum jest w czasie kompilacji do bytecodu zamieniany na „zwykłą” klasę dziedziczącą z java.lang.Enum. Jednak różni się od „zwykłej” klasy flagami:

  flags: (0x4031) ACC_PUBLIC, ACC_FINAL, ACC_SUPER, ACC_ENUM

Obecność flagi ACC_ENUM może potencjalnie odpowiadać za jakieś zachowania, więc wrócimy do niej później.

  public static final dev.jgardo.jvm.miscellaneous.enums.Enum VAL_1;
    descriptor: Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x4019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM

  public static final dev.jgardo.jvm.miscellaneous.enums.Enum VAL_2;
    descriptor: Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x4019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM

Widzimy również dwa pola statyczne finalne z dodatkową flagą ACC_ENUM.

  private final int abc;
  private static final dev.jgardo.jvm.miscellaneous.enums.Enum[] $VALUES;
  public static dev.jgardo.jvm.miscellaneous.enums.Enum[] values();
  public static dev.jgardo.jvm.miscellaneous.enums.Enum valueOf(java.lang.String);
  private dev.jgardo.jvm.miscellaneous.enums.Enum(int);

W kolejnych liniach widzimy pole, które zadeklarowaliśmy w enumie, a następnie wygenerowane pole statyczne finalne z wszystkimi wartościami enuma o nazwie $VALUES, a po nim kolejne dwie wygenerowane statyczne metody. Pierwsza zwraca wszystkie możliwe wartości, a druga zwraca wartość enuma dla podanego Stringa.
Następnie widzimy zadeklarowany wcześniej konstruktor.

Na samym końcu listingu z javap znajduje się wygenerowana inicjalizacja wartości enumów (pól statycznych finalnych) oraz wypełnienie wartościami wspomnianej wcześniej tablicy $VALUES.

Czyli to zwykła klasa?

Można by się pokusić o stwierdzenie, że tak właściwie to słowo kluczowe enum służy do ograniczenia boilerplate’u poprzez wygenerowanie zwykłej klasy Javowej. Być może równie dobrze taki boilerplate możnaby ograniczyć jakąś adnotacją Lombokową….
Czy więc zatem można by taki enum stworzyć „ręcznie”? Warto spróbować zamienić klasę Enum

public enum Enum {
    VAL_1(1),
    VAL_2(2);

    private final int abc;
    Enum(int abc) {
        this.abc = abc;
    }
}

na odpowiadającą jej implementację wygenerowanej klasy Enuma czyli:

public class Enum extends java.lang.Enum<Enum> {
    public static final Enum VAL_1 = new Enum("VAL_1", 1, 1);
    public static final Enum VAL_2 = new Enum("VAL_2", 2, 2);

    private final int abc;
    private static final Enum[] $VALUES = new Enum[] {VAL_1, VAL_2 };
    public static Enum[] values() {
        return $VALUES;
    }

    public static Enum valueOf(String name) {
        return valueOf(Enum.class, name);
    }
    Enum(String name, int ordinal, int abc) {
        super(name, ordinal);
        this.abc = abc;
    }
}

Okazuje się, że enum jest uprzywilejowany na kilka sposobów.

1. switch pozwala na używanie enumów w case. Polega to na wywołaniu metody ordinal() enuma, co jest równe liczbie porządkowej wartości danego enuma. Dzięki temu case może dotyczyć już zwykłych intów co jest standardowym mechanizmem (zamiana wartości Enuma na wartości ordinal(), również jest automatyczna i nie widać tego w kodzie, choć w bytecodzie jest to widoczne).
Jeśli chcielibyśmy stworzyć własnoręcznie klasę, wywołanie ordinal() musialo by być jawne, co zmniejsza czytelność kodu.

2. Tworzenie obiektem z użyciem refleksji jest dla enumów zablokowane. Szybki test:

    public static void main(String[] args) throws Exception {
        var constructor = Enum.class.getDeclaredConstructors()[0];
        constructor.setAccessible(true);
        var generated = constructor.newInstance("VAL_G", 2, 2);
        System.out.println(generated);
    }

powoduje równie szybki błąd:

Exception in thread "main" java.lang.IllegalArgumentException: Cannot reflectively create enum objects
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:484)
	at dev.jgardo.jvm.miscellaneous.enums.EnumExperiment.main(EnumExperiment.java:18)

Jeśli spojrzymy w implementację (Constructor.newInstance(Constructor.java:484)), to za to rzucenie wyjątku jest uwarunkowane obecnością wspomnianej wcześniej flagi ACC_ENUM dla danej klasy.

3. Instancje enumów można wykorzystywać w adnotacjach, instancje zwykłych klas – nie. Generalnie to jest duża przewaga, a osiągana jest ona znów dzięki fladze ACC_ENUM dla klasy.

4. Enumy są dobrze przystosowane do serializacji obiektów, które je posiadają – po deserializacji otrzymywany jest istniejący enum, a nie jakiś kolejny nowo stworzony enum (a tak by było przy w przypadku zwykłej klasy).

5. W zasadzie na końcu najważniejsze – tego sie normalnie nie da skompilować 😛 Kompilator javac uniemożliwia „ręczne” stworzenie klasy dziedziczącej po java.lang.Enum
Oświadcza to dosadnie komunikatem przy kompilacji:
Enum.java:3: error: classes cannot directly extend java.lang.Enum

Podsumowanie

Można by w skrócie powiedzieć, że enum niby jest taką zwykła klasą, ale jednak nie 😉 Bez wsparcia ze strony JVMa i kompilatora nie można by go używać w tak elastyczny sposób (w adnotacjach, switchu, serializacji). Z drugiej strony można też powiedzieć, że całość implementacji jest dosyć intuicyjna i przewidywalna i że nie ma tam jakiejś specjalnej „magii”.

Z perspektywy czasu można śmiało powiedzieć, że dodanie osobnego słowa kluczowego było krokiem w dobrą stronę.

I na koniec obiecany cały listing javap -v -p:

Classfile /home/gardziol/repository/jvm-miscellaneous/target/classes/dev/jgardo/jvm/miscellaneous/enums/Enum.class
  Last modified 6 paź 2019; size 1137 bytes
  MD5 checksum 18c950a8da67456a2509b83e2dfe7d36
  Compiled from "Enum.java"
public final class dev.jgardo.jvm.miscellaneous.enums.Enum extends java.lang.Enum<dev.jgardo.jvm.miscellaneous.enums.Enum>
  minor version: 0
  major version: 55
  flags: (0x4031) ACC_PUBLIC, ACC_FINAL, ACC_SUPER, ACC_ENUM
  this_class: #4                          // dev/jgardo/jvm/miscellaneous/enums/Enum
  super_class: #13                        // java/lang/Enum
  interfaces: 0, fields: 4, methods: 4, attributes: 2
Constant pool:
   #1 = Fieldref           #4.#40         // dev/jgardo/jvm/miscellaneous/enums/Enum.$VALUES:[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
   #2 = Methodref          #41.#42        // "[Ldev/jgardo/jvm/miscellaneous/enums/Enum;".clone:()Ljava/lang/Object;
   #3 = Class              #20            // "[Ldev/jgardo/jvm/miscellaneous/enums/Enum;"
   #4 = Class              #43            // dev/jgardo/jvm/miscellaneous/enums/Enum
   #5 = Methodref          #13.#44        // java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
   #6 = Methodref          #13.#45        // java/lang/Enum."<init>":(Ljava/lang/String;I)V
   #7 = Fieldref           #4.#46         // dev/jgardo/jvm/miscellaneous/enums/Enum.abc:I
   #8 = String             #14            // VAL_1
   #9 = Methodref          #4.#47         // dev/jgardo/jvm/miscellaneous/enums/Enum."<init>":(Ljava/lang/String;II)V
  #10 = Fieldref           #4.#48         // dev/jgardo/jvm/miscellaneous/enums/Enum.VAL_1:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #11 = String             #16            // VAL_2
  #12 = Fieldref           #4.#49         // dev/jgardo/jvm/miscellaneous/enums/Enum.VAL_2:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #13 = Class              #50            // java/lang/Enum
  #14 = Utf8               VAL_1
  #15 = Utf8               Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #16 = Utf8               VAL_2
  #17 = Utf8               abc
  #18 = Utf8               I
  #19 = Utf8               $VALUES
  #20 = Utf8               [Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #21 = Utf8               values
  #22 = Utf8               ()[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #23 = Utf8               Code
  #24 = Utf8               LineNumberTable
  #25 = Utf8               valueOf
  #26 = Utf8               (Ljava/lang/String;)Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #27 = Utf8               LocalVariableTable
  #28 = Utf8               name
  #29 = Utf8               Ljava/lang/String;
  #30 = Utf8               <init>
  #31 = Utf8               (Ljava/lang/String;II)V
  #32 = Utf8               this
  #33 = Utf8               Signature
  #34 = Utf8               (I)V
  #35 = Utf8               <clinit>
  #36 = Utf8               ()V
  #37 = Utf8               Ljava/lang/Enum<Ldev/jgardo/jvm/miscellaneous/enums/Enum;>;
  #38 = Utf8               SourceFile
  #39 = Utf8               Enum.java
  #40 = NameAndType        #19:#20        // $VALUES:[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #41 = Class              #20            // "[Ldev/jgardo/jvm/miscellaneous/enums/Enum;"
  #42 = NameAndType        #51:#52        // clone:()Ljava/lang/Object;
  #43 = Utf8               dev/jgardo/jvm/miscellaneous/enums/Enum
  #44 = NameAndType        #25:#53        // valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
  #45 = NameAndType        #30:#54        // "<init>":(Ljava/lang/String;I)V
  #46 = NameAndType        #17:#18        // abc:I
  #47 = NameAndType        #30:#31        // "<init>":(Ljava/lang/String;II)V
  #48 = NameAndType        #14:#15        // VAL_1:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #49 = NameAndType        #16:#15        // VAL_2:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
  #50 = Utf8               java/lang/Enum
  #51 = Utf8               clone
  #52 = Utf8               ()Ljava/lang/Object;
  #53 = Utf8               (Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
  #54 = Utf8               (Ljava/lang/String;I)V
{
  public static final dev.jgardo.jvm.miscellaneous.enums.Enum VAL_1;
    descriptor: Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x4019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM

  public static final dev.jgardo.jvm.miscellaneous.enums.Enum VAL_2;
    descriptor: Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x4019) ACC_PUBLIC, ACC_STATIC, ACC_FINAL, ACC_ENUM

  private final int abc;
    descriptor: I
    flags: (0x0012) ACC_PRIVATE, ACC_FINAL

  private static final dev.jgardo.jvm.miscellaneous.enums.Enum[] $VALUES;
    descriptor: [Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x101a) ACC_PRIVATE, ACC_STATIC, ACC_FINAL, ACC_SYNTHETIC

  public static dev.jgardo.jvm.miscellaneous.enums.Enum[] values();
    descriptor: ()[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=1, locals=0, args_size=0
         0: getstatic     #1                  // Field $VALUES:[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
         3: invokevirtual #2                  // Method "[Ldev/jgardo/jvm/miscellaneous/enums/Enum;".clone:()Ljava/lang/Object;
         6: checkcast     #3                  // class "[Ldev/jgardo/jvm/miscellaneous/enums/Enum;"
         9: areturn
      LineNumberTable:
        line 3: 0

  public static dev.jgardo.jvm.miscellaneous.enums.Enum valueOf(java.lang.String);
    descriptor: (Ljava/lang/String;)Ldev/jgardo/jvm/miscellaneous/enums/Enum;
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=1, args_size=1
         0: ldc           #4                  // class dev/jgardo/jvm/miscellaneous/enums/Enum
         2: aload_0
         3: invokestatic  #5                  // Method java/lang/Enum.valueOf:(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Enum;
         6: checkcast     #4                  // class dev/jgardo/jvm/miscellaneous/enums/Enum
         9: areturn
      LineNumberTable:
        line 3: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      10     0  name   Ljava/lang/String;

  private dev.jgardo.jvm.miscellaneous.enums.Enum(int);
    descriptor: (Ljava/lang/String;II)V
    flags: (0x0002) ACC_PRIVATE
    Code:
      stack=3, locals=4, args_size=4
         0: aload_0
         1: aload_1
         2: iload_2
         3: invokespecial #6                  // Method java/lang/Enum."<init>":(Ljava/lang/String;I)V
         6: aload_0
         7: iload_3
         8: putfield      #7                  // Field abc:I
        11: return
      LineNumberTable:
        line 19: 0
        line 20: 6
        line 21: 11
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      12     0  this   Ldev/jgardo/jvm/miscellaneous/enums/Enum;
            0      12     3   abc   I
    Signature: #34                          // (I)V

  static {};
    descriptor: ()V
    flags: (0x0008) ACC_STATIC
    Code:
      stack=5, locals=0, args_size=0
         0: new           #4                  // class dev/jgardo/jvm/miscellaneous/enums/Enum
         3: dup
         4: ldc           #8                  // String VAL_1
         6: iconst_0
         7: iconst_1
         8: invokespecial #9                  // Method "<init>":(Ljava/lang/String;II)V
        11: putstatic     #10                 // Field VAL_1:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
        14: new           #4                  // class dev/jgardo/jvm/miscellaneous/enums/Enum
        17: dup
        18: ldc           #11                 // String VAL_2
        20: iconst_1
        21: iconst_2
        22: invokespecial #9                  // Method "<init>":(Ljava/lang/String;II)V
        25: putstatic     #12                 // Field VAL_2:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
        28: iconst_2
        29: anewarray     #4                  // class dev/jgardo/jvm/miscellaneous/enums/Enum
        32: dup
        33: iconst_0
        34: getstatic     #10                 // Field VAL_1:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
        37: aastore
        38: dup
        39: iconst_1
        40: getstatic     #12                 // Field VAL_2:Ldev/jgardo/jvm/miscellaneous/enums/Enum;
        43: aastore
        44: putstatic     #1                  // Field $VALUES:[Ldev/jgardo/jvm/miscellaneous/enums/Enum;
        47: return
      LineNumberTable:
        line 4: 0
        line 10: 14
        line 3: 28
}
Signature: #37                          // Ljava/lang/Enum<Ldev/jgardo/jvm/miscellaneous/enums/Enum;>;
SourceFile: "Enum.java"
 

Czym tak naprawdę jest Lambda w Javie

Jak dobrze pamiętamy, największym osiągnięciem w Javie 8 było wprowadzenie wyrażeń lambda. W tym poście skupię się na tym czym one technicznie są oraz jak one działają.

Pierwsze spostrzeżenia

Jeśli spojrzeć w przeszłość, to przed Javą 8 wyrażenia lambda były emulowane wewnętrznymi klasami anonimowymi. Przykładowo w dla wcześniejszych wersji Javy dla przetwarzania funkcyjnego stworzono klasę Iterables. A w niej zalecanym podejściem było tworzenie anonimowych klas wewnętrznych implementujące interfejsy z jedną metoda. Jakkolwiek było to dość toporne rozwiązanie trzeba było tworzyć dużo zbędnego kodu…

Czy może zatem lambda jest zwykłą wewnętrzna klasa anonimową? Wskazywałby na to również stacktrace zrobiony wewnątrz lambdy w którym widać charakterystyczny dla klas anonimowych znak $, a po nim numer klasy.

public class LambdaExperiment {
    public static void main(String[] args) {
        Function<String, Void> lambda = s -> { throw new RuntimeException(s); };
        lambda.apply("String");
    }
}
Exception in thread "main" java.lang.RuntimeException: String
	at dev.jgardo.jvm.miscellaneous.lambda.LambdaExperiment.lambda$main$0(LambdaExperiment.java:7)
	at dev.jgardo.jvm.miscellaneous.lambda.LambdaExperiment.main(LambdaExperiment.java:8)

I teoria ta miałaby szanse, gdyby nie to, że wśród skompilowanych plików .class nie ma żadnych dodatkowych klas, a każda klasa anonimowa tworzy osobny plik o sufiksie $<nrKlasyAnonimowej>

Gdzie zatem jest ta lambda?

Cóż… trzeba zajrzeć do kodu bajtowego, może tam coś znajdziemy…

  Last modified 27 wrz 2019; size 1461 bytes
  MD5 checksum f165faff2e94d85a93129e64e8cd7403
  Compiled from "LambdaExperiment.java"
public class dev.jgardo.jvm.miscellaneous.lambda.LambdaExperiment
  minor version: 0
  major version: 55
  flags: (0x0021) ACC_PUBLIC, ACC_SUPER
  this_class: #6                          // dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment
  super_class: #7                         // java/lang/Object
  interfaces: 0, fields: 0, methods: 3, attributes: 3
Constant pool:
   #1 = Methodref          #7.#29         // java/lang/Object."<init>":()V
   #2 = InvokeDynamic      #0:#35         // #0:apply:()Ljava/util/function/Function;
   #3 = String             #36            // String
   #4 = InterfaceMethodref #37.#38        // java/util/function/Function.apply:(Ljava/lang/Object;)Ljava/lang/Object;
   #5 = Methodref          #39.#40        // java/lang/String.toUpperCase:()Ljava/lang/String;
   #6 = Class              #41            // dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment
   #7 = Class              #42            // java/lang/Object
   #8 = Utf8               <init>
   #9 = Utf8               ()V
  #10 = Utf8               Code
  #11 = Utf8               LineNumberTable
  #12 = Utf8               LocalVariableTable
  #13 = Utf8               this
  #14 = Utf8               Ldev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment;
  #15 = Utf8               main
  #16 = Utf8               ([Ljava/lang/String;)V
  #17 = Utf8               args
  #18 = Utf8               [Ljava/lang/String;
  #19 = Utf8               lambda
  #20 = Utf8               Ljava/util/function/Function;
  #21 = Utf8               LocalVariableTypeTable
  #22 = Utf8               Ljava/util/function/Function<Ljava/lang/String;Ljava/lang/String;>;
  #23 = Utf8               lambda$main$0
  #24 = Utf8               (Ljava/lang/String;)Ljava/lang/String;
  #25 = Utf8               s
  #26 = Utf8               Ljava/lang/String;
  #27 = Utf8               SourceFile
  #28 = Utf8               LambdaExperiment.java
  #29 = NameAndType        #8:#9          // "<init>":()V
  #30 = Utf8               BootstrapMethods
  #31 = MethodHandle       6:#43          // REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
  #32 = MethodType         #44            //  (Ljava/lang/Object;)Ljava/lang/Object;
  #33 = MethodHandle       6:#45          // REF_invokeStatic dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment.lambda$main$0:(Ljava/lang/String;)Ljava/lang/String;
  #34 = MethodType         #24            //  (Ljava/lang/String;)Ljava/lang/String;
  #35 = NameAndType        #46:#47        // apply:()Ljava/util/function/Function;
  #36 = Utf8               String
  #37 = Class              #48            // java/util/function/Function
  #38 = NameAndType        #46:#44        // apply:(Ljava/lang/Object;)Ljava/lang/Object;
  #39 = Class              #49            // java/lang/String
  #40 = NameAndType        #50:#51        // toUpperCase:()Ljava/lang/String;
  #41 = Utf8               dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment
  #42 = Utf8               java/lang/Object
  #43 = Methodref          #52.#53        // java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
  #44 = Utf8               (Ljava/lang/Object;)Ljava/lang/Object;
  #45 = Methodref          #6.#54         // dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment.lambda$main$0:(Ljava/lang/String;)Ljava/lang/String;
  #46 = Utf8               apply
  #47 = Utf8               ()Ljava/util/function/Function;
  #48 = Utf8               java/util/function/Function
  #49 = Utf8               java/lang/String
  #50 = Utf8               toUpperCase
  #51 = Utf8               ()Ljava/lang/String;
  #52 = Class              #55            // java/lang/invoke/LambdaMetafactory
  #53 = NameAndType        #56:#60        // metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
  #54 = NameAndType        #23:#24        // lambda$main$0:(Ljava/lang/String;)Ljava/lang/String;
  #55 = Utf8               java/lang/invoke/LambdaMetafactory
  #56 = Utf8               metafactory
  #57 = Class              #62            // java/lang/invoke/MethodHandles$Lookup
  #58 = Utf8               Lookup
  #59 = Utf8               InnerClasses
  #60 = Utf8               (Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
  #61 = Class              #63            // java/lang/invoke/MethodHandles
  #62 = Utf8               java/lang/invoke/MethodHandles$Lookup
  #63 = Utf8               java/lang/invoke/MethodHandles
{
  public dev.jgardo.jvm.miscellaneous.lambda.LambdaExperiment();
    descriptor: ()V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 5: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Ldev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment;

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: (0x0009) ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=2, args_size=1
         0: invokedynamic #2,  0              // InvokeDynamic #0:apply:()Ljava/util/function/Function;
         5: astore_1
         6: aload_1
         7: ldc           #3                  // String String
         9: invokeinterface #4,  2            // InterfaceMethod java/util/function/Function.apply:(Ljava/lang/Object;)Ljava/lang/Object;
        14: pop
        15: return
      LineNumberTable:
        line 7: 0
        line 8: 6
        line 9: 15
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      16     0  args   [Ljava/lang/String;
            6      10     1 lambda   Ljava/util/function/Function;
      LocalVariableTypeTable:
        Start  Length  Slot  Name   Signature
            6      10     1 lambda   Ljava/util/function/Function<Ljava/lang/String;Ljava/lang/String;>;

  private static java.lang.String lambda$main$0(java.lang.String);
    descriptor: (Ljava/lang/String;)Ljava/lang/String;
    flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokevirtual #5                  // Method java/lang/String.toUpperCase:()Ljava/lang/String;
         4: areturn
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0     s   Ljava/lang/String;
}
SourceFile: "LambdaExperiment.java"
InnerClasses:
  public static final #58= #57 of #61;    // Lookup=class java/lang/invoke/MethodHandles$Lookup of class java/lang/invoke/MethodHandles
BootstrapMethods:
  0: #31 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #32 (Ljava/lang/Object;)Ljava/lang/Object;
      #33 REF_invokeStatic dev/jgardo/jvm/miscellaneous/lambda/LambdaExperiment.lambda$main$0:(Ljava/lang/String;)Ljava/lang/String;
      #34 (Ljava/lang/String;)Ljava/lang/String;

W listingu javap -p -v znaleźliśmy ciało wyrażenia lambda w osobnej, wygenerowanej metodzie o nazwie lambda$main$0 (linia 114), które przyjmuje takie same argumenty jak nasza poszukiwana lambda oraz posiada nazwę, którą widzieliśmy w stacktrace. Jest tam również pewna rzadka instrukcja invokedynamic wprowadzona w Javie 7 (linia 95).

Wciąż jednak nie mamy tej wewnętrznej klasy anonimowej…

Teoria

W projekcie Lambda, twórcy Javy stwierdzili, że jest wiele możliwości implementacji lambd, a każda ma zalety i wady (anonimowa klasa wewnętrzna, dynamiczne proxy, MethodHandle). Nie chcieli się wiązać z żadną implementacją, żeby mieć w przyszłości ewentualną swobodę zmiany koncepcji. Dlatego też stwierdzili, dostarczeniem odpowiedniej implementacji lambdy zajmie się JVM w czasie wykonywania.

Implementacja lambd używa mechanizmu wprowadzonego w poprzedniej wersji Javy – wersji 7 – invokedynamic.
Gdy JVM po raz pierwszy dojdzie do danej instrukcji invokedynamic musi „dowiedzieć się” jaką metodę ma wykonać (w przeciwieństwie do pozostałych instrukcji bytecode z rodziny invoke, na etapie kompilacji nie znamy docelowej wywoływanej metody; znamy tylko metodę, która wskaże co trzeba robić). W przypadku definiowania lambdy, aby się tego dowiedzieć, wywoływana jest metoda java.lang.invoke.LambdaMetafactory.metafactory (linia 132 listingu). W parametrach przekazywane są m. in. uchwyt do wygenerowanej na etapie kompilacji metody tworzącej treść lambdy, jej sygnatura, sygnatura metody interfejsu funkcyjnego, którego implementacji szukamy. Metoda generuje docelową klasę z lambdą, ładuje ją oraz zwraca „fabrykę” obiektów tej klasy.

Po stworzeniu fabryki jest ona przypisywana do danej instrukcji invokedynamic.

Raz stworzona i związana z daną instrukcją invokedynamic fabryka jest następnie używana do uzyskania obiektu implementującego interfejs funkcyjny (lambdę).

Takie podejście ma swoje zalety:
– nie wiążemy się z implementacją wyrażeń lambd (ewentualnie można je zmienić)
– mniejszy rozmiar bytecode’u pozbawionego klas wewnętrznych oraz mniejsza ilość osobnych plików d0 załadowania
– brak możliwości ingerowania w kod lambd – nikt nie będzie grzebał w bytecodzie, którego nie ma 😉
– możliwość cache’owania bezstanowych lambd – nie trzeba zawsze tworzyć nowych obiektów.

Rozwiązanie zagadki

Każda implementacja JVM może mieć inną implementację metody. OpenJDK 11 używa wygenerowanych zaraz przed pierwszym użyciem, a następnie cache’owanych klas wewnętrznych (InnerClassLambdaMetafactory).

Więcej informacji:

Temat jest dość trudny i skomplikowany. Starałem się opisać go w dość prostych słowach, więc mogą być pewne nieścisłości. Aby ich uniknąć należało by ten artykuł rozszerzyć o dokładniejszy opis invokedynamic, bootstrap methods, method handle, callsite, jednak wówczas byłby znacznie dłuższy…
Ponadto wytłumaczyłem tylko najprostszy przykład – lambda bezstanowa. Wiadomo, że w lambdach można korzystać z efektywnie finalnych zmiennych lokalnych, co komplikuje proces tworzenia wyrażeń lambda. Co więcej (o zgrozo!) lambdy mogą być serializowalne…

Po dokładny opis wyżej wymienionych problemów polecam sięgnąć do Briana Goetza (człowieka odpowiedzialnego za projekt Lambda w OpenJDK) w artykule Translation of Lambda Expressions.
Jeśli ktoś chce lepiej zrozumieć jak działa invokedynamic polecam bardzo dobrą prezentację Waldemara Kota youtube lub slajdy.

Koniec!
O ile subskrypcji nie ma, o tyle jest tu kanał RSS (jeszcze nie testowałem;) )

 

Switch

Pierwsze, co może kojarzyć się ze switch-case to szereg następujących po sobie bloków if else. Z pewnością taki blok switch case jest bardziej czytelny aniżeli szereg if else. Jednak każdy zna jakąś sytuację, w której jakiś znajomy w pracy zapomniał dodać break na koniec bloku case, co prowadziło do błędów biznesowych, technicznych lub błędów bezpieczeństwa. A skoro ten break jest przeważnie konieczny, to nie do końca pasuje do teorii o ciągu if elseów. Jaka jest prawda o switch?

Code

Ok, czas na trochę kodu. Zacznijmy od prostej metody, która w zależności od argumentu zwraca różne wartości. Zaimplementowana będzie dwukrotnie – najpierw za pomocą switch, następnie z użyciem ifów.

    public int switchInt9(CountToNine countToNine) {
        int i = countToNine.i;
        switch (i) {
            case 0: return 0;
            case 1: return 8;
            case 2: return 16;
            case 3: return 24;
            case 4: return 32;
            case 5: return 40;
            case 6: return 48;
            case 7: return 56;
            default:
                return 64;
        }
    }

    public int ifInt9(CountToNine countToNine) {
        int i = countToNine.i;
        if (i == 0) {
            return 0;
        } else if (i == 1) {
            return 8;
        } else if (i == 2) {
            return 16;
        } else if (i == 3) {
            return 24;
        } else if (i == 4) {
            return 32;
        } else if (i == 5) {
            return 40;
        } else if (i == 6) {
            return 48;
        } else if (i == 7) {
            return 56;
        } else  {
            return 64;
        }
    }

Stworzyłem też analogiczne metody z 33 wpisami zamiast 9.

Po skompilowaniu takich metod, a następnie zdekompilowaniu z użyciem javap -v widzimy obydwie metody. Pierwsza z użyciem switch wygląda tak:

  public int switchInt9(dev.jgardo.jvm.miscellaneous.switches.SwitchBenchmark$CountToNine);
    descriptor: (Ldev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine;)I
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=1, locals=3, args_size=2
         0: aload_1
         1: invokestatic  #22                 // Method dev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine.access$000:(Ldev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine;)I
         4: istore_2
         5: iload_2
         6: tableswitch   { // 0 to 7
                       0: 52
                       1: 54
                       2: 57
                       3: 60
                       4: 63
                       5: 66
                       6: 69
                       7: 72
                 default: 75
            }
        52: iconst_0
        53: ireturn
        54: bipush        8
        56: ireturn
        57: bipush        16
        59: ireturn
        60: bipush        24
        62: ireturn
        63: bipush        32
        65: ireturn
        66: bipush        40
        68: ireturn
        69: bipush        48
        71: ireturn
        72: bipush        56
        74: ireturn
        75: bipush        64
        77: ireturn

W tym przypadku widzimy instrukcję kodu bajtowego tableswitch z pożądanymi wartościami podawanymi przy case i numerem instrukcji do której ma „skoczyć” jeśli wartość się zgadza. (o tableswitch więcej poniżej)

Dla ifów bytecode wygląda następująco:

  public int ifInt9(dev.jgardo.jvm.miscellaneous.switches.SwitchBenchmark$CountToNine);
    descriptor: (Ldev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine;)I
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=2
         0: aload_1
         1: invokestatic  #22                 // Method dev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine.access$000:(Ldev/jgardo/jvm/miscellaneous/switches/SwitchBenchmark$CountToNine;)I
         4: istore_2
         5: iload_2
         6: ifne          11
         9: iconst_0
        10: ireturn
        11: iload_2
        12: iconst_1
        13: if_icmpne     19
        16: bipush        8
        18: ireturn
        19: iload_2
        20: iconst_2
        21: if_icmpne     27
        24: bipush        16
        26: ireturn
        27: iload_2
        28: iconst_3
        29: if_icmpne     35
        32: bipush        24
        34: ireturn
        35: iload_2
        36: iconst_4
        37: if_icmpne     43
        40: bipush        32
        42: ireturn
        43: iload_2
        44: iconst_5
        45: if_icmpne     51
        48: bipush        40
        50: ireturn
        51: iload_2
        52: bipush        6
        54: if_icmpne     60
        57: bipush        48
        59: ireturn
        60: iload_2
        61: bipush        7
        63: if_icmpne     69
        66: bipush        56
        68: ireturn
        69: bipush        64
        71: ireturn

W przypadku ciągu if elseów widzimy… ciąg if elseów… Czyli na poziomie bytecode’u switch nie jest ukrytą opcją if elseową.

Trochę teorii

Otóż w zamyśle do obsługi słowa kluczowego switch stworzono specjalnie dwie instrukcje bytecodu – tableswitch oraz lookupswitch.
Zamysł był prosty: zamiast wielokrotnie porównywać z coraz innymi wartościami, na etapie kompilacji stworzymy tablicę par „wartość-adres skoku do instrukcji”. Następnie wystarczyłoby poszukać odpowiedniej wartości w tablicy i skoczyć do tej instrukcji, którą wskazuje.
Dla tableswitch wyszukiwanie jest proste – wystarczy spojrzeć pod index tablicy, której wartości szukamy. Jeśli szukamy wartości 5, to skaczemy do tej instrukcji, którą wskazuje tablica pod indeksem 5. Wówczas czas obliczenia miejsca kolejnej instrukcji jest stały tzn. O(1).

Niestety nie zawsze w case szukamy kolejnych liczb porządkowych zaczynając od zera. Czasem są to różne wartości, które nie są w żaden sposób uporządkowane, ani powiązane. Dla takich wartości została stworzona instrukcja lookupswitch. Na etapie kompilacji wszystkie wartości są sortowane. Następnie w runtimie szukamy odpowiedniej wartości używając algorytmu wyszukiwania binarnego znajdywana jest odpowiednia wartość. Dzięki takiemu mechanizmowi możemy znaleźć odpowiednią wartość w czasie logarytmicznym tzn. O(log2(n)).

Oczekiwania vs rzeczywistość

Wydaje się, że taka optymalizacja ma szanse prowadzić do szybszego działania kodu. Oszczędzamy przede wszystkim na wielokrotnym porównywaniu.

A jaka jest rzeczywistość?
Uruchomiłem odpowiednie wspomniane na początku metody jako benchmarki (kod na moim githubie). Mierzyłem przepustowość, czyli ilość operacji na sekundę (im więcej tym lepiej).
Wyniki na moim lapku na JVM OpenJDK w wersji 8 (java-8-openjdk-amd64) są następujące:

SwitchBenchmark.ifInt33      thrpt   10  22022234,398 ± 247287,924  ops/s
SwitchBenchmark.switchInt33  thrpt   10  20090372,745 ± 105013,436  ops/s

SwitchBenchmark.ifInt9       thrpt   10  28632436,517 ± 107714,521  ops/s
SwitchBenchmark.switchInt9   thrpt   10  27754974,543 ± 177176,911  ops/s

Okazuje się, że ciąg if elseów jest szybszy, aniżeli sprawdzenie w tabeli miejsca do instrukcji skoku. Dlaczego?

Otóż taka implementacja switch miała sens w początkach Javy – w drugiej połowie lat 90. Wtedy procesory były dość wolne jak na dzisiejsze standardy, a odczyty z pamięci RAM były względem procesorów całkiem szybkie. Jeśli odczyt z pamięci trwał wówczas kilka cykli procesora wówczas miało to sens. Z biegiem lat wymyślono takie mechanizmy jak wielordzeniowość, pipelining, branch prediction, które znacznie przyspieszyły wykonywanie instrukcji kodu maszynowego nie przyspieszając taktowania (a równocześnie taktowanie zwiększyło się kilku(nasto)krotnie).

O ile skoki warunkowe if mogły w miarę bezboleśnie podlegać tym usprawnieniom, o tyle skok bezwarunkowy do adresu odczytanego z tabeli pod indexem wyliczonym w poprzedniej instrukcji dość skutecznie blokuje owe usprawnienia. Zatem zaleta stała się wadą, co skutkuje gorszą wydajnością…

Jeśli spojrzymy na kod maszynowy skompilowany przezc2 w openjdk8 zauważymy wspomniany fragment kodu maszynowego (skok pod adres wskazany przez wartość w rejestrze)

  0x00007f872101185d: jmpq    *(%r8,%r10)       ;*tableswitch
                                                ; - dev.jgardo.jvm.miscellaneous.switches.SwitchBenchmark::switchInt33@6 (line 96)

OpenJDK vs OracleJDK

Szczęśliwie twórcy OracleJdk 8 stwierdzili, że to może być pewien mało wydajny mechanizm w dzisiejszych czasach, więc po kompilacji c2 instrukcje switch case zostają zamienione na ciąg if elseów (w końcu za coś każą płacić za licencję komercyjną :p).

Niestety switch jest zamieniany na ify dla 9 case, gdy dla 33 caseów dalej jest domyślna implementacja switch

Myśli ostateczne

Wiele o switch można by jeszcze mówić. Można wspomnieć o:

  • implementacji switch na Enum i String (o tym dużo w internecie)
  • zamianie kolejności ifów przy konwersji switch -> if w zależności od statystyki wywołań
  • switch expression
  • i bazującym na nim pattern matching

No nic… Koniec postu, zostawcie łapkę w górę i kliknijcie dzwoneczek, czy inne takie 😉

 

Hello World

Cześć!

będę tu pisać o programowaniu!

A tak będzie widać kod?
Nie… znajdę jakąś lepszą wtyczkę 😉

I generalnie to czekam na domenę… jgardo.dev 😉

Edit: domena jest, jakichś highlighter również, więc można blogować 😉

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}