JVM Weekly #99 - Mój stary to fanatyk teorii garbage collectorów...

1. Srogi refactor G1

Mój stary to fanatyk teorii garbage collectorów. Pół mieszkania zaj*bane wydaniami ’Garbage Collection Algorithms for Automatic Dynamic Memory Management’ i ‘The Garbage Collection Handbook’, najgorsze. Średnio raz w miesiącu ktoś odpali jakąś Springowy Hello World, a tu java.lang.OutOfMemoryError: GC Overhead Limit Exceeded, bo się bawił nowościami G1 z inkubacji i trzeba system przywracać, bo nie można dojść do ładu, które flagi kompilatora i gdzie zmodyfikował. W swoim 22 letnim życiu już z 10 razy powtarzałem ten proces, od kiedy JDK wychodzi co pół roku i ciągle są jakieś „rewolucyjne nowości do przetestowania”. Tydzień temu chciałem po prostu zainstalować patcha security, to system operacyjny od razu zasugerował instalacje „na świeżo” xD bo kernel myślał, że znowu mi Java nie działa.

Jeżeli utożsamiacie się z powyższym i chcecie znaleźć z ojcem wspólny język, to mam dla Was do polecenia dobrą publikację. Otóż okazało się, że już niedługo G1 zostanie mocno zmodyfikowany jeśli chodzi o internale całości i mechanizm tak zwanego „znakowania” (marking). Takowe w G1 wykorzystuje algorytm snapshot-at-the-beginning(SATB) – tzn. G1 robi wirtualną migawkę zawartości Heapa na początku całego procesu. Ze względu na fakt, że G1 umożliwia wielowątkowe „sprzątanie”, na jego potrzeby sporo struktur było duplikowane. Twórcom jednak udało przerobić tak, że uniknęli niepotrzebnej redundancji, a to wszystko dzięki sprytnemu wykorzystaniu zależności między już istniejącymi strukturami. Całość została opisana przez autora, Thomasa Schatzla z Oracle w publikacji Concurrent Marking in G1

Co do zalet, pamięć wykorzystywana do bitmap jest dwukrotnie mniejsza niż w przypadku istniejącego mechanizmu: teraz aż 3% Java Heapu będzie zarezerwowane na potrzeby G1. Także im większa ilość pamięci przeznaczonej na potrzeby JVM, tym więcej korzyści przyniesie migracja.

Zmiany efektywnie wejdą w życie wraz z JDK 20.

A jeżeli nie zrozumieliście niczego z powyższego posta (i nie ma się czego tu wstydzić – mnie również wielokrotnie autor zgubił po drodze), to albo musicie zapytać wspomnianego we wstępie fanatyka Garbage Collectorów, albo zapoznać się ze znacznie przystępniejszą publikacją Michała Piotrowskiego prowadzącego blog Bare.Metal.Dev. Końcem zeszłego roku rozpoczął on serie o wdzięcznej nazwie GC Theory, w której dzieli się swoimi notatkami z lektury dwóch wspaniałych cegieł: wspomnianych w paście ‘Garbage Collection Algorithms for Automatic Dynamic Memory Management’ oraz ‘The Garbage Collection Handbook’, będących legendarnymi pozycjami jeśli chodzi o działania „odśmiecaczy.” Całość pozwala spojrzeć na te legendarne pozycje książkowe mocno Javo-centrycznym okiem Michała.

Źródła

2. Release Radar: Micronaut 3.6.0

Drugą z tegotygodniowich nowości jest premiera nowego Micronauta. Co przynosi wydanie Micronaut 3.6.0?.

Dopiero co tydzień pisałem o nowym GraalVM, a ten już trafił do Micronauta. Co prawda twórcy nie chwalą się, jakie nowości bezpośrednio dla ich frameworka za tym idą, ale już sam fakt wprowadzenia poprawek dawanych przez bazowego GraalVM (repozytorium bibliotek ❤️) sprawia, że używający „natywnego” Micronauta nie powinni długo wahać się nad migracją.

Co jednak dla tych, którzy nie wskoczyli jeszcze na graalvm-owy wagonik? Dla nich pojawił się nowy moduł – Micronaut Test Resources – który dodaje wsparcie dla zarządzania zewnętrznymi zasobami potrzebnymi na potrzeby testów. To, co sam moduł daje, to w zasadzie integracja z Testcontainers, nie wymagająca żadnej dodatkowej konfiguracji. Dzięki temu Micronaut sam odpali sobie np. niezbędną instancje bazy danych. Wspierane są w zasadzie wszystkie najważniejsze systemy – PostgreSQL, MongoDB, Kafka, Redis czy ElasticSearch, a także wiele innych. Dodatkowo, twórcy dostarczyli dwa pluginy – jeden do Gradle, drugi do Mavena, umożliwiający konfigurację tej funkcjonalności.

To właśnie integracjami zresztą nowe wydanie Micronauta stoi, ponieważ poza powyższymi twórcy chwalą się kolejnymi dodatkami. Przykładowo, Micronaut Tracing dostał wsparcie dla formatu OpenTelemetry, dzięki czemu z miejsca stał się kompatybilny z większością popularnych rynkowych rozwiązań. Dodane zostało też wsparcie dla Hibernate Reactive w ramach modułu Micronaut Data. Umożliwia on też wybranie Hibernate Reactive na poziomie generowania projektu. Jeżeli zaś już dawno przerzuciliście się na jOOQa, ten też w ramach nowego wydania został zaktualizowany do najnowszej wersji – również pierwszej w pełni reaktywnej.