Używanie szczegółowych informacji: gc (tylko w systemachAIX, Linux )

Opcji -verbose:gc można użyć z opcją -Xgc:verboseGCCycleTime=N , aby zapisywać informacje w konsoli na temat aktywności programu Metronome Garbage Collector. Nie wszystkie właściwości XML w danych wyjściowych produktu -verbose:gc ze standardowej maszyny JVM są tworzone lub stosowane do danych wyjściowych narzędzia Metronome Garbage Collector.

Użyj opcji -verbose:gc , aby wyświetlić minimalną, maksymalną i średnią wolną pamięć sterty. W ten sposób można sprawdzić poziom aktywności i użycia sterty, a następnie dopasować wartości, jeśli to konieczne. Opcja -verbose:gc zapisuje statystyki Metronome w konsoli.

Opcja -Xgc:verboseGCCycleTime=N określa częstotliwość pobierania informacji. Określa czas (w milisekundach), przez który podsumowania są zrzucane. Wartość domyślna N wynosi 1000 milisekund. Czas cyklu nie oznacza, że podsumowanie jest zrzucane właśnie w tym czasie, ale po ostatnim zdarzeniu czyszczenia pamięci, które spełnia to kryterium czasu. Gromadzenie i wyświetlanie tych statystyk może zwiększyć ilość czasu wstrzymania programu Metronome Garbage Collector, a ponieważ N jest mniejsze, czasy przerwy mogą stać się duże.

Quantum to pojedynczy okres działania Metronome Garbage Collector, który powoduje przerwanie lub wstrzymanie dla aplikacji.

Przykład szczegółów: gc output

Wpisz:

java -Xgcpolicy:metronome -verbose:gc -Xgc:verboseGCCycleTime=N myApplication

Gdy wyzwalane jest czyszczenie pamięci, występuje zdarzenie wyzwalacz uruchamiany wyzwalaczem , po którym następuje dowolna liczba zdarzeń pulsu , a następnie zdarzenie końcowe wyzwalacza , gdy wyzwalacz jest spełniony. W tym przykładzie przedstawiono cykl wyzwalanego czyszczenia pamięci w postaci danych wyjściowych verbose:gc :

<trigger-start id="25" timestamp="2011-07-12T09:32:04.503" /> 

<cycle-start id="26" type="global" contextid="26" timestamp="2011-07-12T09:32:04.503" intervalms="984.285" /> 

<gc-op id="27" type="heartbeat" contextid="26" timestamp="2011-07-12T09:32:05.209">   
  <quanta quantumCount="321" quantumType="mark" minTimeMs="0.367" meanTimeMs="0.524" maxTimeMs="1.878" 
    maxTimestampMs="598704.070" />   
  <exclusiveaccess-info minTimeMs="0.006" meanTimeMs="0.062" maxTimeMs="0.147" />   
  <free-mem type="heap" minBytes="99143592" meanBytes="114374153" maxBytes="134182032" />   
  <thread-priority maxPriority="11" minPriority="11" />
</gc-op> 

<gc-op id="28" type="heartbeat" contextid="26" timestamp="2011-07-12T09:32:05.458">   
  <quanta quantumCount="115" quantumType="sweep" minTimeMs="0.430" meanTimeMs="0.471" maxTimeMs="0.511" 
    maxTimestampMs="599475.654" />   
  <exclusiveaccess-info minTimeMs="0.007" meanTimeMs="0.067" maxTimeMs="0.173" />   
  <classunload-info classloadersunloaded=9 classesunloaded=156  />     
  <references type="weak" cleared="660" />   
  <free-mem type="heap" minBytes="24281568" meanBytes="55456028" maxBytes="87231320" />   
  <thread-priority maxPriority="11" minPriority="11" />
</gc-op> 

<gc-op id="29" type="syncgc" timems="136.945" contextid="26" timestamp="2011-07-12T09:32:06.046">   
  <syncgc-info reason="out of memory" exclusiveaccessTimeMs="0.006" threadPriority="11" />   
  <free-mem-delta type="heap" bytesBefore="21290752" bytesAfter="171963656" />
</gc-op> 

<cycle-end id="30" type="global" contextid="26" timestamp="2011-07-12T09:32:06.046" /> 

<trigger-end id="31" timestamp="2011-07-12T09:32:06.046" />

Mogą wystąpić następujące typy zdarzeń:

< wyzwalacz-początek ... >: Początek cyklu czyszczenia pamięci, gdy ilość używanej pamięci stała się większa niż wartość progowa wyzwalacza. Domyślna wartość progowa wynosi 50% sterty. Atrybut intervalms to odstęp czasu między poprzednim zdarzeniem trigger end (z id-1) i tym zdarzeniem trigger start .
< wyzwalacz-koniec ... >: Cykl czyszczenia pamięci pomyślnie obniżył ilość używanej pamięci poniżej progu wyzwalacza. Jeśli cykl czyszczenia pamięci został zakończony, ale wykorzystana pamięć nie została pominięta poniżej progu wyzwalacza, nowy cykl czyszczenia pamięci jest uruchamiany z tym samym identyfikatorem kontekstu. Dla każdego zdarzenia trigger start istnieje pasujące zdarzenie trigger end o tym samym identyfikatorze kontekstu. Atrybut intervalms to odstęp czasu między poprzednim zdarzeniem produktu trigger start a bieżącym zdarzeniem produktu trigger end . W tym czasie co najmniej jeden cykl czyszczenia pamięci zostanie zakończony do momentu, gdy zajęte pamięci nie zostaną usunięte poniżej progu wyzwalacza.
< gc-op id="28 "type="heartbeat" ... >: Zdarzenie okresowe, które zbiera informacje (na temat pamięci i czasu) dotyczące wszystkich kwantów czyszczenia pamięci na czas pokryty. Zdarzenie pulsu może wystąpić tylko między zgodną parą zdarzeń trigger start i trigger end , to znaczy, gdy aktywny cykl czyszczenia pamięci jest w trakcie przetwarzania. Atrybut intervalms jest to odstęp czasu między poprzednim zdarzeniem pulsu (z id -1) i tym zdarzeniem pulsu.
< gc-op id="29 "type="syncgc" ... >: Synchroniczne (nondeterministyczne) zdarzenie czyszczenia pamięci. Patrz sekcja Synchroniczne czyszczenie pamięci

Znaczniki XML w tym przykładzie mają następujące znaczenie:

< quanta ... >: Podsumowanie kwantowych czasów pauzy w okresie pulsu, w tym długość pauzy w milisekundach.
< free-mem type = "heap " ... >: Podsumowanie ilości wolnego miejsca w stercie w okresie pulsu, próbkowane na końcu każdego kwantu czyszczenia pamięci.
< classunload-info classloadersunloaded=9 classesunloaded=156 />: Liczba programów ładujących klasy i klas, które zostały rozładowane w okresie pulsu.
< referencje type="weak " cleared="660 />: Liczba i typ obiektów odwołania Java™ , które zostały wyczyszczone w okresie pulsu.

Uwaga:

Jeśli w przedziale między dwoma pulsami pulsacji wystąpił tylko jeden kwantowy proces czyszczenia pamięci, to wolna pamięć jest próbkowana tylko na końcu tego jednego kwantu. Oznacza to, że wartości minimalne, maksymalne i średnie podane w podsumowaniu pulsu są równe.
Odstęp czasu między dwoma zdarzeniami pulsu może być znacznie większy niż określony czas trwania cyklu, jeśli sterta nie jest w pełni wystarczająca, aby wymagać działania czyszczenia pamięci. Na przykład, jeśli program wymaga działania czyszczenia pamięci tylko raz na kilka sekund, puls może być wyświetlony tylko raz na kilka sekund.
Możliwe jest, że odstęp czasu może być znacznie większy niż określony czas cyklu, ponieważ czyszczenie pamięci nie działa na stercie, które nie jest wystarczająco pełne, aby można było uzasadniać działanie czyszczenia pamięci. Na przykład, jeśli program wymaga działania czyszczenia pamięci tylko raz na kilka sekund, puls może być wyświetlony tylko raz na kilka sekund.
Jeśli wystąpi zdarzenie, takie jak synchroniczne czyszczenie pamięci lub zmiana priorytetu, szczegóły zdarzenia oraz zdarzenia oczekujące, takie jak pulsy, są natychmiast generowane jako dane wyjściowe.
Jeśli maksymalna kwantowa ilość czyszczenia pamięci dla danego okresu jest zbyt duża, można zmniejszyć wykorzystanie miejsca docelowego za pomocą opcji -Xgc:targetUtilization . To działanie daje Garbage Collector więcej czasu na pracę. Alternatywnie można zwiększyć wielkość sterty za pomocą opcji -Xmx . Podobnie, jeśli aplikacja może tolerować dłuższe opóźnienia niż jest to obecnie zgłaszane, można zwiększyć wykorzystanie miejsca docelowego lub zmniejszyć wielkość sterty.
Dane wyjściowe można przekierować do pliku dziennika, a nie do konsoli z opcją -Xverbosegclog:<file> , na przykład -Xverbosegclog:out zapisuje dane wyjściowe -verbose:gc do pliku out.
Priorytet wymieniony w thread-priority jest podstawowym priorytetem wątku systemu operacyjnego, a nie priorytetem wątku Java.

Synchroniczne operacje czyszczenia pamięci

Wpis jest również zapisywany w dzienniku produktu -verbose:gc po wystąpieniu synchronicznego (niedeterministycznego) czyszczenia pamięci. To zdarzenie ma trzy możliwe przyczyny:

Jawne wywołanie System.gc() w kodzie.
W maszynie JVM zabraknie pamięci, a następnie wykonuje synchroniczną operację czyszczenia pamięci, aby uniknąć warunku OutOfMemoryError .
Maszyna JVM zostanie wyłączona podczas ciągłego czyszczenia pamięci. Maszyna JVM nie może anulować gromadzenia danych, dlatego kończy zbieranie danych synchronicznie, a następnie kończy działanie.

Przykładem wpisu System.gc() jest:

<gc-op id="9" type="syncgc" timems="12.92" contextid="8" timestamp=
"2011-07-12T09:41:40.808">
  <syncgc-info reason="system GC" totalBytesRequested="260" exclusiveaccessTimeMs="0.009" 
  threadPriority="11" />
  <free-mem-delta type="heap" bytesBefore="22085440" bytesAfter="136023450" />
  <classunload-info classloadersunloaded="54" classesunloaded="234" />
  <references type="soft" cleared="21" dynamicThreshold="29" maxThreshold="32" />
  <references type="weak" cleared="523" />
  <finalization enqueued="124" />
</gc-op>

Przykładem synchronicznej pozycji czyszczenia pamięci w wyniku wyłączenia maszyny JVM jest:

<gc-op id="24" type="syncgc" timems="6.439" contextid="19" timestamp="2011-07-12T09:43:14.524">   
  <syncgc-info reason="VM shut down" exclusiveaccessTimeMs="0.009" threadPriority="11" />   
  <free-mem-delta type="heap" bytesBefore="56182430" bytesAfter="151356238" />   
  <classunload-info classloadersunloaded="14" classesunloaded="276" />   
  <references type="soft" cleared="154" dynamicThreshold="29" maxThreshold="32" /> 
  <references type="weak" cleared="53" />   
  <finalization enqueued="34" />
</gc-op>

Znaczniki XML i atrybuty w tym przykładzie mają następujące znaczenie:

< gc-op id="9 "type="syncgc" timems= "6.439" ...: Ten wiersz wskazuje, że typ zdarzenia jest synchronicznym czyszczeniem pamięci. Atrybut timems to czas trwania synchronicznej operacji czyszczenia pamięci (w milisekundach).
< syncgc-info reason=" ... " />: Przyczyna synchronicznego czyszczenia pamięci.
< free-mem-delta .../>: Wolna pamięć sterty Java przed synchronicznym czyszczeniem pamięci (w bajtach) przed i po synchronicznym czyszczeniu pamięci.
< finalization .../>: Liczba obiektów oczekujących na finalizację.
< classunload-info .../>: Liczba programów ładujących klasy i klas, które zostały rozładowane w okresie pulsu.
< referencje type="weak " cleared="53" .../>: Liczba i typ obiektów odwołań Java, które zostały wyczyszczone w okresie pulsu.

Synchroniczne czyszczenie pamięci ze względu na warunki braku pamięci lub zamknięcie maszyny wirtualnej może wystąpić tylko wtedy, gdy kolektor czyszczenia jest aktywny. Musi ona być poprzedzona zdarzeniem start wyzwalacza , chociaż niekoniecznie musi być natychmiast. Niektóre zdarzenia pulsu mogą wystąpić między zdarzeniem wyzwalacz start i zdarzeniem synchgc . Synchroniczna operacja czyszczenia pamięci spowodowana przez program System.gc() może wystąpić w dowolnym momencie.

Śledzenie wszystkich kwantów GC

Poszczególne kwanty GC można śledzić, umożliwiając śledzenie punktów śledzenia GlobalGCStart i GlobalGCEnd . Te punkty śledzenia są generowane na początku i na końcu wszystkich działań Metronome Garbage Collector, w tym synchronicznych operacji czyszczenia pamięci. Dane wyjściowe dla tych punktów śledzenia wyglądają podobnie do następujących:

03:44:35.281 0x833cd00 j9mm.52 - GlobalGC start: globalcount=3

03:44:35.284 0x833cd00 j9mm.91 - GlobalGC end: workstackoverflow=0 overflowcount=0

Pozycje braku pamięci

Gdy sterta zabraknie wolnego miejsca, wpis jest zapisywany w dzienniku produktu -verbose:gc , zanim zostanie zgłoszony wyjątek OutOfMemoryError . Przykładowe dane wyjściowe to:

<out-of-memory id="71" timestamp="2011-07-12T10:21:50.135" memorySpaceName="Metronome" 
  memorySpaceAddress="0806DFDC"/>

Domyślnie program Javadump jest generowany w wyniku wyjątku OutOfMemoryError . Ten zrzut zawiera informacje na temat pamięci używanej przez program użytkownika.

NULL
1STSEGTOTAL    Total memory:           4066080 (0x003E0B20)
1STSEGINUSE    Total memory in use:    3919440 (0x003BCE50)
1STSEGFREE     Total memory free:       146640 (0x00023CD0)