Przed Java 6, JVM HotSpot alokował każdy obiekt na stercie, niezależnie od czasu życia. Wraz z wprowadzeniem Kompilator serwerowy (C2), JVM zyskał Analizę ucieczek (EA), statyczną technikę analizy, która określa, czy odniesienie do obiektu ucieka z bieżącej metody lub wątku. Gdy EA udowodni, że obiekt pozostaje lokalny dla metody, aktywuje się Zastępowanie skalarne jako agresywna optymalizacja.
Optymalizacja dekomponuje obiekt na jego skalarne pola składowe, alokując je na stosie lub w rejestrach CPU zamiast na stercie. Eliminuje to koszty alokacji i związane z nimi obciążenie GC całkowicie. Jednak optymalizacja napotyka twardą granicę, gdy spotyka się z blokami synchronized, ponieważ monitory wymagają stabilnego nagłówka obiektu na stercie do zarządzania kolejkami kontencji.
public int calculate() { Point p = new Point(1, 2); // Może być zastąpiony skalarne return p.x + p.y; }
W silniku handlowym wysokiej częstotliwości przetwarzającym miliony wydarzeń rynkowych na sekundę, logika dopasowania zamówień tworzyła miliony tymczasowych obiektów Coordinate do obliczania nachylenia cen. Te alokacje wywoływały częste kolekcje młodej generacji, powodując nieakceptowalne mikrosekundowe przerwy podczas szczytowej zmienności. Zespół inżynieryjny musiał wyeliminować te alokacje bez poświęcania czytelności kodu lub gwarancji bezpieczeństwa.
Pierwszym podejściem było wdrożenie puli obiektów przy użyciu ThreadLocal w celu ponownego wykorzystania instancji Coordinate w różnych obliczeniach. Chociaż to zmniejszyło churn sterty, wprowadziło kontencję linii pamięci podręcznej, gdy wiele wątków uzyskiwało dostęp do sąsiednich wpisów mapy ThreadLocal i wymagało złożonej logiki do obsługi sprzątania zakończeń wątków. Dodatkowo, logika synchronizacji zwiększyła czasoverhead operacji na poziomie nanosekund, co zniweczyło zyski wydajności.
Inną alternatywą było przeniesienie przechowywania współrzędnych do pamięci poza stertą za pomocą ByteBuffer lub Unsafe, ręcznie zarządzając przesunięciami bajtów, aby całkowicie unikać GC. To podejście eliminowało obciążenie sterty, ale poświęcało bezpieczeństwo typów, wymagało ręcznej kontroli zakresu i komplikowało debugowanie, ponieważ zrzuty sterty już nie ujawniały stanu współrzędnych. Obciążenie utrzymania uznano za zbyt wysokie dla krytycznego systemu handlowego.
Zespół ostatecznie zdecydował się na refaktoryzację klasy Coordinate, aby była niemutowalna i zapewniała, że wszystkie metody obliczeniowe pozostały wolne od synchronizacji, co pozwoliło na działanie zastępowania skalarnego w modelu C2. Zweryfikowali optymalizację, uruchamiając z -XX:+PrintEscapeAnalysis, potwierdzając w dziennikach wiadomości "Zastąpione skalarne". Wymagało to usunięcia obronnego kopiowania, które wcześniej zmuszało do alokacji na stercie, ale było niepotrzebne dla obliczeń lokalnych dla wątków.
Wdrożenie skończyło się zerowymi alokacjami dla gorącej ścieżki podczas pracy w stanie ustalonym, redukując czas przerwy GC o 40% i poprawiając przepustowość o 15%. Ponieważ kod pozostał czystym Java bez niebezpiecznych konstrukcji, rozwiązanie zachowało pełne możliwości debugowania i przenośności poprzez wersje JVM. Doświadczenie pokazało, że rozumienie optymalizacji kompilatora jest często lepsze niż ręczne zarządzanie pamięcią.
Dlaczego zastępowanie skalarne nie działa, gdy obiekt jest przypisany do pola innego obiektu, nawet jeśli ten kontener nigdy nie ucieka?
Analiza ucieczek działa na poziomie granularity metody i nie zawsze może udowodnić globalną widoczność pól. Gdy obiekt jest przechowywany w polu za pomocą bajtkodu putfield, kompilator ostrożnie zakłada, że odniesienie może uciec, chyba że może udowodnić, że zewnętrzny obiekt pozostaje ograniczony do stosu przez wszystkie możliwe ścieżki kodu. To ograniczenie uniemożliwia zastępowanie skalarne, ponieważ kompilator nie może zagwarantować, że pole nie zostanie dostępne przez inne wątki lub między ponownymi wejściami do metody, zmuszając do alokacji na stercie w celu utrzymania spójności pamięci.
Jak obecność metody finalize() całkowicie wyłącza zastępowanie skalarne dla klasy?
Mechanizm Finalizer wymaga, aby obiekty rejestrowały się w globalnej kolejce referencji monitorowanej przez dedykowany wątek systemowy. Ta rejestracja zachodzi w trakcie konstrukcji obiektu za pomocą wywołania rodzimych, które natychmiast publikują odniesienie do obiektu na stercie, powodując, że ucieka on z lokalnego zasięgu. Ponieważ zastępowanie skalarne wymaga, aby obiekt nigdy nie materializował się jako jednostka sterty, każda klasa nadpisująca Object.finalize() jest bezwarunkowo wykluczona z tej optymalizacji, nawet jeśli finalizator jest pusty.
Czy zastępowanie skalarne może wystąpić w metodach kompilowanych przez kompilator C1?
Zastępowanie skalarne jest zarezerwowane dla Kompilatora C2 (serwerowego), ponieważ C1 priorytetowo traktuje szybkość kompilacji nad głęboką analizą statyczną. C1 wykonuje tylko podstawowe optymalizacje, takie jak składanie stałych i inlining, nie mając rozwiniętej struktury Analizy ucieczek, potrzebnej do udowodnienia ograniczenia obiektów. W konsekwencji, obiekty o krótkim czasie życia w metodach, które pozostają na poziomach kompilacji od 1 do 3, zawsze będą powodować alokacje na stercie, tworząc szczyty alokacji podczas rozgrzewania JVM przed zakończeniem kompilacji poziomu 4 przez C2.