Początkowa i maksymalna wielkość sterty

Informacje na temat operacji czyszczenia pamięci (Garbage Collector-GC) ułatwiają ustawianie początkowych i maksymalnych wielkości sterty na potrzeby wydajnego zarządzania stertą.

Funkcja czyszczenia pamięci dostosowuje wielkość sterty w celu utrzymania zajętości między 40% a 70% z następujących powodów:
  • Zajęcie sterty większe niż 70% powoduje częstsze cykle GC, co może zmniejszyć wydajność. To zachowanie można zmienić, ustawiając opcję -Xminf .
  • Zajętość sterty mniejsza niż 40% oznacza rzadko powtarzające się cykle czyszczenia pamięci. Cykle te są jednak dłuższe niż niezbędne, powodując dłuższe czasy przerwy, co może zmniejszyć wydajność. To zachowanie można zmienić, ustawiając opcję -Xmaxf .
Jeśli nie zostanie ustawiona początkowa lub maksymalna wielkość sterty, proces czyszczenia pamięci zostanie rozwinięty i rozkurczy stertę zgodnie z wymaganiami. Jeśli jednak wielkość sterty zostanie naprawiona za pomocą opcji -Xms i -Xmx , czyszczenie pamięci Java™ nie zostanie rozwinięte ani zmniejszone. Aby zoptymalizować wydajność aplikacji i utrzymać zakres 40-70%, maksymalne ustawienie wielkości sterty powinno być o co najmniej 43% większe niż maksymalne zajętość aplikacji. Na przykład, jeśli dla aplikacji istnieje maksymalna zajętość 70 MB, należy ustawić maksymalną wielkość sterty równą 100 MB, tak jak to pokazano w poniższym obliczeniu:
70 + (70 * 43/100)

Ustawienie minimalnej i maksymalnej wielkości sterty na tę samą wartość zwykle nie jest dobrym pomysłem, ponieważ czyszczenie pamięci jest opóźniane do momentu zapełnienia sterty. W związku z tym po raz pierwszy proces czyszczenia pamięci może potrwać dłużej. Ponadto, sterta jest bardziej prawdopodobna, że jest fragmentowana i wymaga upakowania sterty. Uruchom aplikację, używając minimalnej wielkości sterty, której wymaga aplikacja. Gdy czyszczenie pamięci jest uruchamiane, jest ono uruchamiane często i efektywnie, ponieważ sterta jest mała.

Jeśli czyszczenie pamięci nie może znaleźć wystarczającej ilości śmieci, zostanie uruchomione upakowanie. Jeśli czyszczenie pamięci spowoduje znalezienie wystarczającej ilości śmieci lub spełniony jest dowolny z pozostałych warunków dla rozszerzenia sterty (patrz Przydzielanie sterty w Dokumentacja użytkownika produktu OpenJ9), czyszczenie pamięci jest rozwinięte.

Z tego powodu aplikacja jest zwykle uruchamiana do momentu zapełnienia sterty. Następnie kolejne cykle czyszczenia pamięci odzyskują śmieci. Gdy sterta jest zapełniana obiektami na żywo, czyszczenie pamięci jest kompilowane. Jeśli nadal nie ma wystarczającej ilości czyszczenia pamięci, czyszczenie pamięci powoduje rozwinięcie sterty.

Z wcześniejszego opisu widać, że czyszczenie pamięci powoduje kompilację sterty jako potrzeby wzrostu aplikacji, dzięki czemu w miarę rozszerzania sterty jest on rozwijany z zestawem zgrabionych obiektów w dolnej części oryginalnej sterty. Ten proces jest wydajnym sposobem zarządzania stertą, ponieważ upakowanie jest uruchamiane na najmniejszej wielkości sterty w momencie, gdy działanie upakowania jest konieczne. Upakowanie jest wykonywane z minimalnymi wielkościami sterty, które rośnie. Istnieją pewne dowody na to, że początkowy zestaw obiektów aplikacji ma tendencję do ustawienia klucza lub zestawu głównego, co powoduje, że kompilowanie ich na początku zwalnia pozostałą część sterty w przypadku bardziej krótkotrych obiektów.

W końcu wirtualna maszyna języka Java ma stertę o maksymalnej wielkości, a wszystkie obiekty o długim czasie życia zostały zwarte w dolnej części sterty. Upakowanie miało miejsce, gdy upakowanie było w jego najmniej kosztownej fazie. Ilość przetwarzania i wykorzystania pamięci, która jest wymagana do rozszerzenia sterty, jest niemal trywialna w porównaniu do kosztów gromadzenia i obliczania bardzo dużej sterty podzielonej na fragmenty.