JVM Tuesday vol. 48

1. Wydano GraalVM 21.2

Wiem, że ciągłe czytanie nowości z GraalVM to dla większości osób lizanie cukierka przez papierek, ale tak naprawdę większość najbardziej intrygujących aspektów JVM dzieje się właśnie tam. Teraz wraz z premierą kolejnego “dużego-małego” wydania, twórcy po raz kolejny wprowadzają kilka interesujących nowości, które postaramy się Wam przedstawić w telegraficznym skrócie.

Ze względu na skomplikowanie tematu nie zawsze jest to łatwa sprawa, ale liczymy że docenicie nasze starania.

Przy okazji nowego wydania Spring Native opublikowane zostały pluginy dla natywnych obrazów GraalVM, pozwalające na uruchamianie testów za pomocą JUnita bez konieczności wcześniejszego budowania wariantu aplikacji przeznaczonego na standardowy, JVMowy runtime. Zmiana ta pozwoliła na bardziej precyzyjne testy (natywny kod testowany był w swojej natywnej (hehe) postaci), a także na przyspieszenie całego procesu. Nowe wydanie GraalVM stabilizuje całość, wprowadzając liczne poprawki do tej funkcjonalności.

Z punktu widzenia bezpieczeństwa, bardzo ciekawą zmianą jest również wprowadzenie automatycznego czyszczenia nieużywanych Security Services. Gwoli wyjaśnienia, standard Java Cryptography Architecture (stanowiący część Java Security API) pozwala na dostęp javowych aplikacji do takich szczególnie chronionych usług jak generator liczb losowych czy zasobnik certyfikatów bezpieczeństwa – te “chronione usługi” to właśnie Security Services. Podstawową zasadą bezpieczeństwa jest minimalizowanie wektora potencjalnego ataku, a ze względu na statyczną kompilacje z góry znane są wszystkie niezbędne do poprawnego działania zasoby – co nie jest takie oczywiste w przypadku aplikacji z dynamicznym classpathem. GraalVM został więc wzbogacony o flagę kompilacji, która umożliwia zablokowanie dostępu do wszystkich nieużywanych zasobów bezpieczeństwa.

GraalVM to także lepszy monitoring – natywnie kompilowane aplikacje mają bowiem teraz możliwość bycia moniotorowanym przez coraz powszechniej używany Java Flight Recorder.

To oczywiście nie wszystkie zmiany. Jak zwykle zwiększona została wydajność całej platformy – moją szczególną uwagę zwróciło eksperymentalne wsparcie dla nowoczesnych instrukcji SIMD (Single Instruction Multiple Data), a także predykcja zachowań pętli – nowe heurystyki umożliwiają znacznie agresywniejszą optymalizacje ich wdajności. A jak już mowa o heurystykach – interpreter Truffle otrzymał inteligentniejsze kolejkowanie fragmentów kodu do przetworzenia, co wynikowo ma powodować szybszy start używających go aplikacji.

Musicie przyznać, że jak na pierwszy rzut oka minorową wersje (aczkolwiek numeracja GraalVM jest akurat ciut kontrintuicyjna), zmian jest naprawdę spora ilość. Ale ogólnie chyba wszyscy przywykliśmy do faktu, że w niektórych aspektach świat software zaczął się bardzo szybko poruszać.

Źródła

2. Kwarki JVMa od Alekseya Shipilëva ⚛️

Kojarzycie, kim jest Aleksey Shipilëv (znany pod nickiem @shipilev)? Jeśli nie, to może kojarzycie jedną z jego publikacji – Java Memory Model Pragmatics – która mimo wieku (powstał w 2014 roku) pozostaje jednym z najważniejszych JVMowych tekstów. @shipilev znany może być też jako projektant Garbage Collectora Shenandoah – co nie jest jego jedynym wkładem do OpenJDK, gdyż wcześniej pracował w Oracle, a dziś jest jednym z “opiekunów” tego projektu jako Principal Software Engineer w RedHat. Ogólnie, Aleksey to jedna z tych osób, którą w świecie JVMa zdecydowanie warto śledzić.

Dlatego też z zaciekawieniem śledzimy jego serię JVM Anatomy Quarks. Zawiera ona bardzo specyficzną hmmm… trivie jeśli chodzi o to, jak w swoich bebeszkach działa JVM. Założenie serii jest takie, że każdy post powinien zająć około 5-10 minut i wgłębiać się w jeden temat, pojedynczy test, czy pojedynczą obserwację. Co prawda całość ukazuje się już drugi rok, ale zwykle jest to proces dość skokowy, a poprzedni tydzień przyniósł nam aż pięć “odcinków”, z czego aż trzy dotyczą “branch frequency data” (w moim wolnym tłumaczeniu – “danych częstotliwościowych gałęzi”) – czyli jednej z informacji używanych przez kompilator Hotspot do optymalizacji kodu.

Ogólnie właśnie optymalizacja jest głównym punktem zainteresowania @shipileva – i to raczej taka na poziomie, którym większości programistom nigdy nie będzie dane go dotknąć. Dlaczego więc polecam JVM Anatomy Quarks? Właśnie jako wspomnianą trivie. Nie wiem jak Wy, ale osobiście lubię czasem rozumieć, jak mechanizmy działają “pod maską”, i nawet jeśli poszczególne “kwarki” do niczego mi się nie przydadzą, to lektura całości stanowi fascynujący wgląd w to, jak skomplikowaną maszyną jest JVM. Dodatkowo, całość podana jest w formie ciągle aktualizowanego ebooka, dzięki czemu osoby preferujące czytanie na Kindle’u dostają całość w składnej formie – bo nie okłamujmy się, i tak mało kto kod prezentowany we wspomnianych postach, uruchamia.

Źródła

3. A na koniec… nowości w Kotlin 1.5.30

Nowy cykl releasowy daje o sobie znać. Dopiero co pisaliśmy o Kotlin 1.5.20, a teraz już zaraz spodziewać należy się wydania 1.5.30, które przyznam wzięło mnie trochę z zaskoczenia. Okazuje się bowiem, że jak na kolejnego minora pojawia się w nim kilka dość interesujących nowości.

M1 nie jest już gorącą nowością rozpalającą emocje (aczkolwiek dalej łapki mnie świerzbią, żeby położyć je na laptopiku z tym procesorem), ale tempo jej adopcji przez różnorakie platformy w dalszym stopniu nie przestaje mnie zadziwiać. Kotlin do tej pory uruchamiał się na niej za pomocą środowiska translacyjnego Rosetta (zakładam, że grupa docelowa tego artykułu, jeśli używa Maca, wie o czym mowa), ale wraz z wersją 1.5.30, Kotlin zyskuje pełne natywne wsparcie dla tego wariantu architektur
y ARM.

To jednak nie wszystkie zmiany, aczkolwiek trzeba przyznać, że również reszta będzie relatywnie nietypowa. Pozostając w rezerwacie applowskim – integracji z CocoaPods (managerem zależności dla Swifta i Objective-C) doczekał się oficjalny plugin do budowania aplikacji Kotlin Multiplatform, co z pewnością ułatwi życie tej wciąż dość niszowej grupie tworzącej w języku JetBrains aplikacje na iOSa. Drobnych ulepszeń doczekało się też wsparcie dla Kotlin Native.

To jednak nie wszystko. Od dłuższego czasu trwają prace nad nową reprezentacją pośrednią kodu dla Kotlin/JS, i tak jak 1.5.20, tak i 1.5.30 to krok w kierunku jej implementacji. Nowa wersja przynosi bowiem wsparcie “source map”, które dla większości programistów frontendowych stanowią kluczowe wsparcie przy “odpluskwianiu” źle działających aplikacji. Dzięki mapie źródeł możliwe jest bowiem odniesienie się z poziomu wynikowego, transpilowanego kodu JavaScriptowego do oryginalnych linijek napisanych przez programistę.