Instrukcja bajtowa invokedynamic, wprowadzona w Java 7, opóźnia wiązanie wywołania metody do czasu wykonywania, zamiast rozwiązywać je w czasie kompilacji. Kiedy wyrażenie lambda takie jak () -> System.out.println("x") jest kompilowane, kompilator javac generuje invokedynamic z argumentami bootstrap wskazującymi na LambdaMetafactory.metafactory, zamiast tworzyć oddzielny plik MyClass$1.class, jak miało to miejsce w przypadku anonimowej klasy wewnętrznej new Runnable() { public void run() {...} }. W czasie wykonywania JVM wywołuje tę metodę bootstrap, aby skonstruować CallSite powiązane z MethodHandle wskazującym na ciało lambdy, co pozwala na dynamiczne tworzenie instancji interfejsu funkcjonalnego. To podejście unika wczesnego ładowania klas, narzutów związanych ze statyczną inicjalizacją oraz nadmiaru kodu bajtowego typowego dla klas anonimowych, umożliwiając leniwą inicjalizację i pozwalając kompilatorowi JIT na agresywne wstawienie i optymalizację docelowej metody.
Nasz zespół zarządzał potokiem przetwarzania zdarzeń o wysokiej wydajności, obsługującym miliony zdarzeń telemetrycznych na minutę przy użyciu Java 7. System wykorzystywał liczne anonimowe klasy wewnętrzne do filtrów zdarzeń, co powodowało silne naciski na Metaspace i opóźnione czasy uruchamiania z powodu wczesnego ładowania tysięcy klas syntetycznych. Profilowanie ujawniło, że te klasy konsumowały nadmierną ilość pamięci i wywoływały częste przerwy na zbieranie śmieci podczas szczytów ruchu.
Najpierw rozważaliśmy refaktoryzację do jawnych implementacji wzorca Strategy z wykorzystaniem statycznych finalnych instancji singletonów. To podejście wyeliminowałoby przydziały dla każdej instancji i całkowicie zredukowało użycie Metaspace, unikając opóźnień związanych z ładowaniem klas. Jednak wymagało to napisania znacznej ilości boilerplate code dla każdego filtra, co znacznie zmniejszyło czytelność dla naukowców zajmujących się danymi, którzy utrzymywali logikę biznesową.
Następnie rozważyliśmy migrację do składni Java 8, zachowując jednak wewnętrzny mechanizm klas anonimowych poprzez jawne wywołania konstruktorów w blokach inicjalizacji. Choć to oferowało czystsza składnię, nie przynosiło rzeczywistych korzyści w zakresie wydajności, ponieważ klasy anonimowe są generowane w czasie kompilacji. W związku z tym nadal cierpielibyśmy z powodu narzutu związanego z ładowaniem klas i nadmiaru pamięci, nie zyskując korzyści z czasów wykonywania związanymi z invokedynamic.
Po trzecie, zaproponowaliśmy wykorzystywanie wyłącznie wyrażeń lambda w Java 8 i referencji do metod, polegając na bajtowym kodzie invokedynamic, aby opóźnić generację klas do czasu wykonywania. Ta strategia obiecywała minimalny rozmiar Metaspace dzięki leniwej inicjalizacji i potencjalnej optymalizacji singletonów dla lambd, które nie przechwytują. Niemniej jednak, wymagała starannej rewizji kodu, aby uniknąć przechwytywania zmiennych i ponoszenia nieoczekiwanych kar związanych z przydziałami w scenariuszach o dużym obciążeniu.
Ostatecznie wybraliśmy trzecie rozwiązanie, wprowadzając wytyczne dotyczące kodu, które priorytetowo traktowały referencje do metod bez przechwytywania i proste lambdy nad wyrażeniami przechwytującymi. Ta decyzja zrównoważyła zyski wydajnościowe z łatwością w utrzymaniu składni. Ponadto zapewniło to, że JIT mógł agresywnie optymalizować często wywoływane miejsca wywołań poprzez wstawianie.
Po wdrożeniu, wykorzystanie Metaspace spadło o dziewięćdziesiąt procent, a czas uruchamiania aplikacji zmniejszył się o czterdzieści procent. Zdolności obsługi szczytowego obciążenia znacznie się poprawiły dzięki eliminacji ciśnienia GC z metadanych klas. System mógł teraz płynnie obsługiwać szczyty ruchu bez wcześniejszych opóźnień latencji spowodowanych przerwami w ładowaniu klas.
Dlaczego przechwycone wyrażenie lambda może przydzielać pamięć przy każdym wywołaniu, podczas gdy lambda bez przechwytywania może tego nie robić, i jak to się ma do implementacji invokedynamic?
Gdy lambda przechwytuje zmienne z zewnętrznego zakresu, JVM musi stworzyć nową instancję generowanej klasy interfejsu funkcjonalnego dla każdego odrębnego zestawu przechwyconych wartości za pośrednictwem metody fabrycznej wygenerowanej przez LambdaMetafactory. Z drugiej strony, dla lambd bez przechwytywania metoda bootstrap może połączyć stronę wywołania invokedynamic z fabryką, która wielokrotnie zwraca zbuforowaną instancję singletonu. Kandydaci często błędnie zakładają, że wszystkie lambdy są singletonami, nie zdając sobie sprawy, że semantyka przechwytywania zasadniczo zmienia profil przydziałów i że JIT nie zawsze może pominąć te przydziały, jeśli przechwycone wartości różnią się w każdym wywołaniu.
Jak wykorzystanie invokedynamic dla lambd wpływa na ładowanie klas i SecurityManager, szczególnie w odniesieniu do dostępności prywatnych metod?
Mechanizm invokedynamic przeprowadza kontrole dostępności w czasie wiązania, wykorzystując obiekt Lookup dostarczony przez kontekst wywołującego, który inkapsuluje domenę ładowania klas oraz uprawnienia dostępu. Gdy LambdaMetafactory generuje implementację, używa MethodHandles, które respektują oryginalne modyfikatory dostępu, co oznacza, że prywatne metody wspomniane w lambdach pozostają niedostępne z zewnątrz ich definiującej klasy, nawet poprzez generowaną klasę lambdy. Kandydaci często mylą to z refleksją, która wymaga setAccessible(true) dla prywatnych członków, nie rozumiejąc, że MethodHandles oferują bezpieczniejszą i wydajniejszą ścieżkę, która zachowuje enkapsulację bez negocjacji z SecurityManager w czasie wykonywania.
Jaki jest cel metody altMetafactory w LambdaMetafactory i kiedy byłaby wykorzystywana zamiast standardowej metafactory?
altMetafactory zapewnia rozszerzone możliwości w porównaniu do podstawowej metafactory, wspierając dodatkowe flagi, takie jak FLAG_SERIALIZABLE i FLAG_BRIDGES. Te flagi pozwalają na to, aby generowana lambda implementowała interfejsy znacznikowe, takie jak Serializable, lub zawierała metody mostowe dla zgodności binarnej, gdy interfejs funkcjonalny ma konflikty usuwania typów generycznych. Wiele osób nie zdaje sobie sprawy, że serializowalne lambdy ponoszą dodatkowy narzut czasowy związany z przechwytywaniem struktury SerializedLambda, co ułatwia altMetafactory, zakładając zamiast tego, że serializacja działa identycznie dla wszystkich typów lambd.