Czy istnieje najbardziej "zielona" JVM? Spoiler: jak zwykle to zależy - JVM Weekly vol. 170

1. Jak łatwo używać Visual Studio Code z Javą, prosto z JDConf 2024

Zacznijmy z frontu konferencyjnego. W zeszłym tygodniu mieliśmy bowiem dużą, stricte Javową konferencje online od Microsoftu. JDConf 2024, bo tak się nazywała, miała cztery różne ścieżki (dla trzech różnych stref czasowych), w których to Microsoftowi udało upchnąć bardzo dobre grono spikerów, które pokryło w zasadzie wszystkie tematy, którymi żyje społeczność Javowa w 2024.

Tutaj macie ścieżkę Europejską dla zainteresowanych, resztę znajdziecie pod linkiem.

Były więc nowości w Springu, Wirtualne Wątki, CRaC, AI/LLMy (w tym Microsoftowy Semantic Kernel, którego osobiście używam i w zasadzie to polecam mimo że dalej to de facto testowa wersja projektu), chmura, a nawet projekt Valhalla. Sam dopiero przebijam się przez poszczególne prezentowane tematy (w końcu to łącznie ponad pół doby materiału), ale jest jedno z wystąpień, którym już teraz chciałem się z Wami podzielić.

W swojej sesji From Zero to Java Hero: Visual Studio Code Mastery Loiane Gorner podzieliła się bowiem doświadczeniami z używania Visual Studio Code do tworzenia javowego kodu. Z pewnego punktu widzenia była to najbardziej praktyczna ze wszystkich wystąpień, bo o ile często nie mamy kontroli nad używanym przez nas statkiem technologicznym (kompromisy, wszędzie kompromisy), o tyle używane przez nas IDE / Edytor (zwykle) pozostaje pewną oazą wolności i przejawem pewnego indywidualizmu. A że sam Visual Studio Code bardzo lubię, a bardzo rzadko poświęcam mu miejsce w tych przeglądach – gdzie zwykle jednak ustępuje miejsca IntelliJ Idea – to dzisiaj stwierdziłem, że warto dać mu trochę miłości i „czasu antenowego”.

Dodatkowo, urzekła mnie pewna „multimedialność” publikacji Loiane, która to poza talkiem w ostatnich tygodniach opublikowała Visual Studio Code for Java: The Complete Guide (Tips, Setup, and Extensions) opowiadający, jak w 2024 roku pracować z VSCode w projektach javowych. Artykuł gładko wprowadza w niezbędne kroki, ustawienia i dodatki do VSCode, autorka zaleca rozpoczęcie od Coding Pack for Java, który łączy w sobie VSCode, JDK i niezbędne rozszerzenia, co upraszcza początkowy proces konfiguracji. Przewodnik opisuje poszczególne funkcje, od tych zupełnie podstawowych po zaawansowane, w tym zarządzanie wersjami JDK czy narzędzi testowania i debugowania oraz korzystanie z rozszerzeń do zarządzania projektem, analizy kodu czy bezpieczeństwa aplikacji. Na samej Javie się zresztą tutaj nie kończy – Loiane opisuje też przykładową konfigurację dla Springa, obsługę mikrouserwisów czy integrację z Dockerem.

A żeby zakończyć temat Visual Studio Code, to w lutym ukazała się spora aktualizacja dla oficjalnego rozszerzenia dla Javy od Oracle. Obejmuje ona wsparcie nowych funkcji z świeżo opublikowanego JDK 22, a także wprowadzenie opcji w menu kontekstowym umożliwiającej uruchamianie dowolnego projektu oraz dodane wsparcie dla używania różnych JDK w każdym obszarze roboczym, odchodząc od przestarzałej już konfiguracji jdk.userdir. Ulepszenia obejmują także włączenie testów TestNG do eksploratora testów, funkcję „Idź do testu”, oraz nową konfigurację dla argumentów VM zdefiniowanych przez użytkownika do uruchamiania serwera języka Java.

2. Czy któraś z JVM jest najbardziej „zielona”?

Wszelkiej maści redukcja emisji i ochrona środowiska to kwestie, które ostatnimi laty są coraz bardziej dyskutowane. Osobiście bardzo je lubię, bo to jeden z ciekawszych biznesowych (pomijając oczywiste cost-optimization) tematów, które argumentują pisanie wydajniejszych, lepiej skalujących się aplikacji. Nagle może się okazać, że branżowa zasada „czas programistów jest cenniejszy niż czas serwerów” może przestać obowiązywać, jeśli weźmiemy pod uwagę też koszty środowiskowe. Z drugiej strony, nie wolno się dać zwariować i do tematu podchodzić z głową, sięgając najpierw po najniżej wiszące owoce, a nie robić klasyczną „premature optimization” – bo w oryginalnym cytacie mniej więcje chodziło o to, żeby najpierw optymaliizować algorytm, a nie robić czarną magię na rejestrach procesora, ale całkiem możliwe że też poszukiwanie „odpowiedniej” implementacji maszyny wirtualnej. Czy pomiędzy poszczególnymi wariantami JVM istnieje jakaś różnica pod kątem zużycia energii? Na szczęście ktoś to sprawdził i porównał za nas po inżyniersku.

Żeby nie wpaść w pułapkę krzykliwych nagłówków. PS: „Real ones” też istnieją.

Ionuta Balosin, którego możecie kojarzyć z eksperymentów nad wydajnością JVM, tym razem postanowił pójść za ciosem i w publikacji Analyzing JVM Energy Consumption for JDK 21: An Empirical Study dokładnie zbadać wzorce zużycia energii w różnych JVM. W tym celu skorzystał z linii poleceń, takich jak powerstat i powermetrics, oraz fizycznych urządzeń pomiarowych (takich jak mierniki mocy podłączane do gniazdka), aby zebrać jak najbardziej realne dane o zużyciu energii. Te narzędzia pozwalają ocenić wydajności JVM na różnych architekturach, gdyż powerstat oferuje wgląd w zużycie mocy za pośrednictwem interfejsu Intel’s Running Average Power Limit (RAPL) na systemach GNU/Linux, a powermetrics pełni podobną funkcję na macOS dla architektur ARM64. RAPL jest szczególnie istotny ze względu na szczegółowe raportowanie zużycia energii w różnych komponentach, takich jak CPU i DRAM, w granularny sposób, chociaż nawet on nie obejmuje wszystkich komponentów systemu, takich jak interfejsy sieciowe czy urządzenia do przechowywania danych.

Co ciekawe, tekst ani przez sekundę nie wspomina o Windowsie.

W swoich eksperymentach Balosin przeprowadził testy na szeregu aplikacji, od znanych demo-projektów, takich jak Spring PetClinic i Quarkus Hibernate ORM Panache, po niestandardowe aplikacji, które pozwoliły na zbadania konkretnych wzorców kodowania i ich wpływu na zużycie energii, takie jak poszczególne metody dostępu do pamięci, praktyki logowania, mechanizmy obsługi wyjątków, metody łączenia ciągów znaków oraz algorytmy sortowania o różnej złożoności. Każda JVM była testowana w kontrolowanych warunkach, aby zapewnić sprawiedliwe porównanie, z uwzględnieniem minimalizacji zewnętrznych zmiennych, które mogłyby zniekształcić pomiary, jak zapewnienie odpowiedniego obciążenia JVM.

Wyniki badań nie są rewolucyjne, ale jednak zawierają parę ciekawych obserwacji. Na przykład, Oracle GraalVM Native Image, zwłaszcza gdy jest zoptymalizowany za PGO (Profile-Guided Optimization), wykazał korzystny balans między efektywnością energetyczną a wydajnością, podkreślając potencjalne korzyści z Ahead-of-Time Compilation w celu zmniejszenia zużycia energii w czasie działania. Jednakże oczywiście każdy kij ma dwa końce – wiązało się to z koniecznością wyższego zużycia energii na procesu budowania, a że różnica nie była jakaś wyjątkowo widoczna, to osiągnięcie maksymalnej efektywności energetycznej wymaga odpowiedniej… priorytetyzacji. Ponadto, badanie uwidoczniło złożoność relacji między zużyciem energii a wydajnością w różnych JVM i typach aplikacji, ze względu na ogromną ilość elementów ruchomych. To sprawia, że trudno jest wyciągnąć szerokie wnioski na temat efektywności energetycznej, ponieważ najbardziej efektywna energetycznie JVM w jednym scenariuszu może nie utrzymać tego tytułu w różnych warunkach lub z różnymi typami aplikacji. Wnioski są więc… no właśnie nie ma ich za wiele, ale sam eksperyment jest mega ciekawy i osobiście uwielbiam niezwykłą wnikliwość Ionuta.

A jeśli temat Wam się spodobał, to przyznam, że (jak na początku wspomniałem) sam w tym roku wpadłem w króliczą norę wszelkiej maści tematów związanych sustainability. Dlatego mam dla Was kilka lektur dodatkowych, które sam uważam za szczególnie ciekawe, ale też uwidaczniające, jak złożonym jest poruszany przez nie problem.

Polecam, jeśli chcecie lepiej poczuć klimat tematu. Wystarczająco paperów, abyśmy byli w stanie zrobić sobie takie nasze małe „Papers We Love”. Jest to też efekt mojego researchu, który potrzebowałem na potrzeby nowego talka The State of the Green IT at the beginning of 2024 (spoiler – w maju będę miał okazje go prezentować na JUG Copenhagen, będę pewnie dawał znać). Całość częściowo pokrywa się też z tekstem What is Green IT – Strategies and trends lined out, który miałem kiedyś okazję skrobnąć.

Ostatnią rzeczą, którą chciałem polecić tym, którzy chcieliby sprawdzić efektywność energetyczną swoich aplikacji jest zaś JoularX, czyli Agent Javowy służący właśnie do pomiarów energii, łącznie z rozbiciem na poszczególne metody. Sam używałem go w projektach dla klientów chcących spełnić wymogi wchodzącej w tym roku w życie regulacji CSRD (choć przyznam że głównie na specjalne życzenie, wbrew temu co się o niej sądzi Unia Europejskiej raczej nie będzie Wam benchmarkować kodu) i jest wygodny w użyciu, choć analiza samych danych wymaga nieco samozaparcia.

PS: Jeżeli macie tego typu wyzwania i chcielibyście pogadać jak do tego można podejść, to ja bardzo chętnie wbije się na kawkę. To jest naprawdę interesujący temat.

PS2: A na koniec klasycznie polecam książkę „Not the End of the World”, która pomoże Wam nie zwariować w zalewie wspomnianych wyżej nagłówków. Najgłośniejsza ostatnio pozycja w temacie, bardzo fajnie zniuansowana jeśli chodzi o dobór statystyk.

3. CRaC: Szczegółowy poradnik od AWS oraz wsparcie w Alpaquita Linux

Ostatnim, trochę zaległym tekstem, który jednak bardzo dobrze wpisuje się w mój zakres zainteresowań jest marcowy tekst od AWSa, w którym to dostawca chmurowy opisuje, w jaki sposób używać CRaC-a, aby zapewnić bardziej „natywne chmurowo” użytkownie Javowych aplikacji. Czym jest CRaC wspominałem wielokrotnie (dla nowych osób polecam jedną z poprzednich edycji), ale sumarycznie mówimy tutaj o nakładce na Linuxowy mechanizm CRIU (Checkpoint/Restore In Userspace), który pozwala zrzucić cały proces na dysk twardy, by następnie być w stanie wystartować go z tak zapisanego checkpointu. W publikacji Using CRaC to reduce Java startup times on Amazon EKS AWS prezentuje szczegółową instrukcje, w jaki sposób przejść cały proces, i to na wszystkich warstwach – samej chmury (w tym np. IAM i container registry), poprzez Kubernetesa, Dockera, kończąc na integracji mechanizmu w aplikacji. To chyba pierwszy tak przekrojowy tutorial na który trafiłem, i co pewnie nieco przeraża to fakt, jak dużo jednak kolejnych kroków i elementów ruchomych jest niezbędne, aby móc uzyskać oczekiwane zyski. Efekt zdecydowanie jest tego warty – zejście z 12 sekund do poniżej sekundy to jest zdecydowanie coś, co w wielu przypadkach (ekh ekh – autosklowanie) motywuje do grzebania.

Nieco zabawnym jest zaś, że w artykule przewija się nie własna dystrybucja JDK od Amazonu, czyli Corretto, ale Zulu od Azula. Przypomina to tylko o fakcie, że jednak CRaC nie jest oficjalną częścią OpenJDK, a jedynie opcjonalnym dodatkiem. Dlatego tak naprawdę wspiera go w tej chwili zaledwie właśnie Zulu oraz Liberica od BellSoftu.

Co ciekawe, to właśnie ta ostatnia firma postanowiła uprościć życie wszystkim potencjalnym użytkownikom CRaCa. Jak już wspominałem, instrukcja od Amazonu jest długa i skomplikowana, dlatego inżynierowie z BellSoftu postanowili cały proces nam nieco uprościć. Firma, poza własnym wariantem JDK, tworzy bowiem również własną, opartą na Alpine dystrybucje Linuxa o nazwie Alpaquita, specjalnie sprofilowaną pod użycie z Javą. Ta dostępna jest również w formie gotowych kontenerów, w tym od teraz takich z prekonfigurowanym CRaC-iem. Oczywiście, upraszcza to tylko część z wyzwań, przed którymi stawia nas lektura tekstu AWS-a, ale wydaje się, że warto spróbować Liberici, jeśli szukacie łatwego wejścia w świat CRaCu.