Jak sprawdza się distro Linuxa stworzone pod JVM? Benchmarki Alpaquita Linux robią wrażenie - JVM Weekly #111

1. Znamy pierwsze szczegóły dotyczące JDK 20

Ale ten czas goni – dopiero co cieszyliśmy JDK 19 a już powoli trwają przymiarki do JDK 20. Żebyśmy czasem o tym nie zapomnieli, w zeszłym tygodniu ukazał się oficjalny terminarz, z datami poszczególnych planowanych wydań:

2022/12/08 Rampdown Phase One
2023/01/19 Rampdown Phase Two
2023/02/09 Initial Release Candidate
2023/02/23 Final Release Candidate
2023/03/21 General Availability

Jak więc widzimy, 8 grudnia (Rampdown Phase One) dowiemy się, jakie rzeczy wlecą do nowego wydania i czym będziemy mogli cieszyć się już w marcu. Taki trochę spóźniony Mikołaj.

W sam raz jako przeciwwaga tego, co dzieje się np. w świecie handlu.

No dobra, ale czego się będzie można spodziewać? Jak na razie nie wiemy jeszcze za wiele, a twórcy JDK karty odkrywają wyjątkowo powoli. W kolejce czekają aktualnie trzy JEP’y preview, będące kolejny inkrementem nad już zaprezentowanymi funkcjonalnościami.

Po pierwsze więc JEP 432: Record Patterns (Second Preview). Jest to ciąg dalszy prac nad Pattern Matchingiem w Javie i prezentuje się to następująco:

record Point(int x, int y) {}

static void printSum(Object obj) {
    if (obj instanceof Point p) {
        int x = p.x();
        int y = p.y();
        System.out.println(x+y);
    }
}

Dostałem ostatnio ciekawe pytanie – co tak naprawdę dają nam Rekordy w sytuacji, gdy w zasadzie te same możliwości można uzyskać, dokładając do projektu Lomboka. Są osoby, które wskazują samo generowanie kodu przez Lomboka jako zbytnią „magię”, której chcieliby się pozbyć z projektu. Z mojej perspektywy, biorąc pod uwagę jak wiele innych „magicznych” mechanizmów mamy w ekosystemie, to jest drobnica. Dużo ważniejsze wydaje mi się być to, że na raz zbudowanych rekordach twórcy mogą dodawać kolejne featury, jak naprawdę opisywany JEP 432. Lombok, nie będąc częścią języka, z wiadomych względów nie umożliwia opierania na nim niczego, co dodawane jest do JDK. Dlatego standaryzowanie poszczególnych jego funkcjonalności jest tak istotne.

Dobra, ale wróćmy do meritum. Kontynuując kwestie Pattern Matchingu, JEP 433 to czwarty preview Pattern Matching for switch. Zmiany tak naprawdę są dość kosmetyczne i najważniejszą z mojej perspektywy jest dodanie MatchException, rzucanego w wypadku gdy żaden z możliwych przypadków nie zostanie zmatchowany, przez co zapewniona jest „wyczerpywalność” switchy.

Ale żeby to znaleźć, w taki sposób czytałem nowe Preview…

Ostatnim z opublikowanych ostatnio JEP’ów jest zaś drugie Preview Foreign Function & Memory API. Tutaj znalezienie zmian jest łatwiejsze – dokonano bowiem unifikacji abstrakcji MemoryAddress i MemorySegment, a także zadbano, aby ten ostatni był bardziej użyteczny w kontekście Pattern Matchingu.

To na razie tyle z nowości, których należy się spodziewać w nowym JDK. Prawdopodobnie trafi do niego jednak również…

Źródła

2. ZGC wprowadza Generacje

Był taki okres, że praktycznie każde nowe wydanie JDK przynosiło jakieś istotne zmiany w istniejących Garbage Collectorach, lub też pojawienie się nowych. Widać jednak, że ten temat trochę zastopował – co prawda w dalszym ciągu robione są jakieś drobniejsze poprawki w tym temacie. W ostatnim czasie pojawiła się jednak wczesna wersja interesującej iteracji nad ZGC, o wdzięcznej nazwie Generational ZGC.

W teorii Garbage Collectorów istnieje takie pojęcie jak Hipoteza Generacyjna. W uproszczeniu jest to obserwacja, że w praktyce większość obiektów bardzo szybko nadaje się do sprzątnięcia. Te zaś, które przetrwają pewien okres czasowy, ze sporym prawdopodobieństwem żyły będą jeszcze długo. Większość Garbage Collectorów jest zaprojektowane z myślą o tej właśnie zasadzie.

Wyjątkiem jest tutaj właśnie ZGC – Garbage Collector, który służy do czyszczenia pamięci nawet o wielkości terabajtów bez przerwy dłuższej niż kilka milisekund. ZGC określany jest jako GC nisko-opóźnieniowe, które można uznać za swoisty state-of-the -art jeśli chodzi o maszynę wirtualną Javy. Nie jest to jednak rozwiązanie bez wad – design ZGC jest bardzo skomplikowany. Sprawiło to, że jego pierwsza (obecna) wersja jest jednogeneracyjna, w związku z czym rozwiązanie zawsze miało problem z tak zwanym „oczyszczaniem młodej generacji”, czyli właśnie tych krótko żyjących obiektów. Twórcy od samego początku zapowiadali jednak, że nie poprzestaną na tym i zamierzają generacyjność dodać w późniejszej fazie – można tu przytoczyć choćby talk ZGC: The Next Generation Low-Latency Garbage Collector, zaprezentowane podczas Oracle Developers Live). No i niedawno w nasze ręce trafiła jego wersja Early Access. Nie znalazłem żadnych wiadomości, czy całość trafi do JDK 20, ale liczę, że może doczekamy się tam choćby wersji Preview.

Temat Generacyjnego ZGC poruszany nie wziął nas z zaskoczenia – po raz pierwszy miałem okazje o nim usłyszeć jeszcze w czerwcu, w podcaście inside.java – Episode 24 – „Towards Generational ZGC!”. Jeśli chcecie dowiedzieć się więcej, polecam, zwłaszcza że odcinek jest bardzo „to-the-point” i ma tylko 15 minut.

Źródła

3. BellSoft stworzył dystrybucję Linuxa wyspecjalizowaną do javowych kontenerów

BellSoft jest jednym z najbardziej szanowanych dostawców JDK, tworząca Liberica JDK – najbardziej „wolną” ze wszystkich wersji JDK. Stanowią więc jednego z najważniejszych dostawców platformy uruchomieniowej dla aplikacji Java. Jednak w 2022 Java Developer Kit to tylko jeden z istotnych klocków. Dzisiaj coraz więcej aplikacji pakowane jest w kontenery, w których to trafiają na wszelkiej maści chmury czy inne kubernetesowe klastry. W związku z tym równie duży wpływ na wydajność i bezpieczeństwo aplikacji co dystrybucja JDK może mieć bazowy obraz kontenera, w którym nasza jarka jest uruchamiana.

BellSoft też to chyba zauważył, i postanowił stworzyć nową, referencyjną dystrybucję Linuxa przeznaczoną bezpośrednio do uruchamiania Javy w kontenerach. Na pierwszy rzut oka brzmi to trochę jak strzelanie z armaty do muchy, ale w tym szaleństwie jest metoda. Twórcy wzięli bowiem minimalistycznego Alpine, który sam w sobie dodaje naprawdę minimalny narzut (używałem go w praktyce, jest prawie niezauważalny), ale zmodyfikowali w sposób, który zapewnić ma w wypadku aplikacji JVM-owych znacznie lepsze bezpieczeństwo i wydajność. BellSoft min. stworzył zmodyfikowany wariant alokatora pamięci musl, używanego także przez Alpine, a którego wsparcie zostało dodane całkiem niedawno w JDK 16. Całość nazwali Alpaquita Linux, dodali wsparcie LTS i zapakowali razem ze wcześniej wspomnianym Liberica JDK. Opublikowali też trochę liczb i benchmarków, które mają potwierdzać ich wersję, że udało im się stworzyć najlepiej dostosowany do potrzeb javy i kontenerów dystrybucje Linuxa.

PS: Jeśli jesteście ciekawi historii Liberica JDK – ostatnio Adam Bien w swoim podcaście AirHacks.fm przeprowadził ciekawą rozmowę na ten temat z Dmitrym Chuyko – Performance Architektem w Bellsoft, który zresztą jest autorem powyższych benchmarków.

Jak sprawdza się distro Linuxa stworzone pod JVM? Benchmarki Alpaquita Linux robią wrażenie – JVM Weekly #111

1. Znamy pierwsze szczegóły dotyczące JDK 20

Źródła

2. ZGC wprowadza Generacje

Źródła

3. BellSoft stworzył dystrybucję Linuxa wyspecjalizowaną do javowych kontenerów

Źródła

Odkryj więcej świetnych treści!